RT 2.0.5:
While testing RT205 the following came to my attention/mind:
Some supposed Layout and other bugs:
When viewing Configuration | Global | Group Rights or User Rights, I
have an different look to the other pages - big blue writing, and no
blue/grey frame. There is also a double line as opposed to the other pags
showing a single line between the Navigation Headings and the edit-frame.When a non-priveledged user view a ticket, the ticket info (Ticket Id,
Requestors, CC, etc) above the ticket, is not displayed in the normal
blue/grey box. It seems a bit lost at the top of the page …As non-priveledged user, click on Display Headers - nothing happens -
the functionality is fine, to not display the headers, but I would expect
to then not see the option …When adding users, I am forced to supply a value for the email field -
should this be so? What if the person is just an internet user/operator
and dont have a relevant email address?As non-priveledged user, when viewing my “Your open tickets” box, the
column headers are mis/ill-alligned and not formatted in the same neat
manner as when displaying priveleged user ticket-lists.Often when logging out, I get a “Page cannot be displayed” page. If I
go back en do it again it is fine - but it happens alarmingly often.I dont know if some of these are maybe faults with my installation (I
doubt it …) - let me know if you find/dont find the same.Some suggestions:
When displaying a ticket, the “Interested Parties” fields should maybe
be Bold to accentuate them.When diplaying a list of Items such as Users/Queues/Groups under
Configuration, remove the numbering - this will make it more obviously
alphabetically sorted and align them better.On the ‘Home’ page, in the “25 highest priority tickets I own …”
frame, it would be helpfull if the requestor was displayed.One should maybe be able to edit the subject of a ticket - in case of a
person sending in a request with no heading or just a “FW:”.Can I supply a default Queue to a group/user?
When making changes to the configuration, can the cached objects be
instantly deleted when “saving changes” in an attempt to make the changes
immediate? What other way is there to ensure that group/queue/user rights
are immediately enforced, without the user loging out/in?I hope these are helpfull in bugtracking/fixing.
Rehan van der Merwe
I was messing around with clicking “Brief Headers” and “Full Headers” on a
ticket and noticed this:
When you click on “Full Headers,” on the transaction which you click and on
any transaction physically below it, full headers display, but not on
transactions above the one you clicked. If you subsequently click “Brief
Headers” on any transaction, all of the headers close. This makes sense
given the URLs that appear, but just out of curiosity, what’s the rationale
behind this behavior? Why not display full headers on all tickets or no
tickets, or display only for one particular transaction (as opposed to the
one transaction and any transaction below it)?
O- ~ARK
Hmedicine.com, Inc.
A further question somewhat on this line would be if anyone has an opinion
on whether full headers should include the To: and CC: lists? Since both
the To: and CC: lists can change through time (by modifying the
watchers/requestors), I believe it might be nice to see the list at the
time of the mailing… Thoughts?
Regards,
Christian
Christian Gilmore
Infrastructure & Tools Team Lead
Web & Multimedia Development
IBM Software Group
I was trying to create a scrip that would be used for autoreplying, but only
if the requestor created the ticket. For example, if joe@my.domain creates a
ticket with bob@my.domain as the requestor (via the Web interface), it
shouldn’t autoreply, but if joe@my.domain creates a ticket with himself as
the requestor, it will. And if joe@my.domain submits a ticket via email, it
should autoreply. I wrote the “if” statement below, but it’s not right. I
suspect that the “$session{CurrentUser}->EmailAddress” part isn’t right, but
I suspect something else is wrong too.
if (($self->TransactionObj->Field eq ‘Requestors’) and
($session{CurrentUser}->EmailAddress =~
/$self->TransactionObj->NewValue())/) {
return(1);
}
else {
return(undef);
}
O- ~ARK
I was messing around with clicking “Brief Headers” and “Full Headers” on a
ticket and noticed this:When you click on “Full Headers,” on the transaction which you click and on
any transaction physically below it, full headers display, but not on
transactions above the one you clicked. If you subsequently click “Brief
Headers” on any transaction, all of the headers close. This makes sense
given the URLs that appear, but just out of curiosity, what’s the rationale
behind this behavior?
Sounds like a scoping bug with the “Display headers” flag. it’s not intentional.
Why not display full headers on all tickets or no
tickets, or display only for one particular transaction (as opposed to the
one transaction and any transaction below it)?O- ~ARK
Hmedicine.com, Inc.
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
A REAL sysadmin challenge is “resurrect five dead mailserver while so ripped
to the gills on mdma that you can’t focus on any given line of text for more
than 10 seconds continuously.”
-Nathan Mehl
Yep. this was an improperly scoped variable. It will be
fixed in 2.0.6.On Wed, Aug 15, 2001 at 03:53:55PM -0400, Ayan R. Kayal wrote:
I was messing around with clicking “Brief Headers” and “Full Headers” on a
ticket and noticed this:When you click on “Full Headers,” on the transaction which you click and on
any transaction physically below it, full headers display, but not on
transactions above the one you clicked. If you subsequently click “Brief
Headers” on any transaction, all of the headers close. This makes sense
given the URLs that appear, but just out of curiosity, what’s the rationale
behind this behavior? Why not display full headers on all tickets or no
tickets, or display only for one particular transaction (as opposed to the
one transaction and any transaction below it)?O- ~ARK
Hmedicine.com, Inc.
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.