RT2 bugs and comments

RT Developers
1

I’ve been checking out rt-1-3-49_01 to replace our current working rt 1.0.7
(with a lot of our own modifications). First of all the source of RT2 is MUCH
MUCH MUCH better readable than RT1! I am aware that RT2 is not yet finished
but I had some comments and questions anyway (hope this is not too much for
this list).

  • In the Search/Listing.html page:
    When you select Next page:
    Can’t locate object method “NextPage” via package “RT::Tickets” at
    /vol/RT-2.beta-test/lib/RT/Interface/Web.pm line 232, chunk 377.
    When you try to update search criteria
    Can’t locate object method “OrderBy” via package “RT::Tickets”

  • If a user is not privileged his/her uid does not show in any lists
    (Admin/Users/index.html or Admin/Groups/Members.html)

  • In the SelfService stuff the Preferences link does not work
    (SelfService/Prefs.html does not exist) (what is the SelfService and
    unprivileged stuff for anyway or did i miss some documentation?) (The
    SelfService stuff does not display any requests even if I own them)

  • User interface:
    We currently use RT1 for handling customer requests. Is it possible to
    shield RT2 so that different customers (who would be in different groups)
    will only be able to see their own information? We don’t think our
    customers need to known all our customers and their users. Also the list
    of users in RT2 should not be public in all setups. Can this be
    implemented with a ShowAdministration right (or something equivalent)?

  • Typo: (might be in more places)
    Admin/Global/Scrips.html
    Add a scrip which will apply to all queues:
    ^t

  • Error in outgoing mail:
    If no To: header would be filled in an “Undisclosed recipients” is
    used. Our sendmail says this is an unknown user.
    See patch.outgoingmail

  • In the main screen (home) the “Tickets I requested”
    window is always empty somehow…

  • If you update information on a user the signature is appended with a extra
    new line (probably browser specific still using Netscape 4.75 on Solaris)
    For this and other text areas see patch.textareas.

  • The installed programs in bin have the location of perl hard coded to
    /usr/bin/perl (not modified during install).

  • The CVS directories are installed as well (and the distribution version
    does not contain a useful CVS/Root file. You could consider using the
    pserver CVS/Root here.)

  • In the modify ticket basics (Ticket/Modify.html) there are ‘-’ options for
    queues and status that should not be there.
    See patch.nooptions.
    This probably modifies all status and queue selectors but I couldn’t find
    any place where that would be incorrect and couldn’t think of one either.

  • Just something I think is a little annoying is that almost all files have
    their execute bit set (including README). If you remove the execute bits in
    the CVS repository this can be fixed and instead of chmod 0755 you could
    used chmod u+rwX,go-w,go+rX in the install (is a bit longer but does not
    set unneeded x bits and is more readable).

  • When I receive a notification email the “Requestors” field is set to
    ARRAY(0xfe1918) (instead of a list of requestors) in the template.

  • Shouldn’t a “Take” result in a status change to “open”?

  • What is exactly the difference between the xxAsComment and xx actions?

  • What is exactly the difference between CC and Administrative CC?

  • When a request is created by the mail interface and the mail contains a CC:
    this is not entered into the CC field of the request. Not sure this is
    needed though.

  • Is the next diagram correct for describing mail actions?
    1 Requestors
    2 Owner
    3 CC in ticket
    4 CC in queue (via Admin->Queues->People)
    5 ACC in ticket
    6 ACC in queue (via Admin->Queues->People)
    | 1 | 2 | 3 | 4 | 5 | 6 |
    NotifyRequestor | + | - | - | - | - | - |
    NotifyOwnerAsComment | - | + | - | - | - | - |
    NotifyOwner | - | + | - | - | - | - |
    NotifyAdminWatchersAsComment | - | - | - | - | + | + |
    NotifyAdminWatchers | - | - | - | - | + | + |
    NotifyRequestorAndCcsAsComment| + | - | + | + | ? | ? |
    NotifyRequestorAndCcs | + | - | + | + | ? | ? |
    NotifyAllWatchersAsComment | ? | ? | + | + | + | + |
    NotifyAllWatchers | ? | ? | + | + | + | + |

  • When using the [Users] and [Groups] links in the [Administration] menu
    there is no easy way to select a different user when a user (or group) is
    already selected. The [Users] and [Groups] links don’t work then. This is
    annoying.

Ok that’s it for now. I’ll try a newer version soon and see what problems I
run in to. RT2 looks very promising.

– arthur de jong - arthur@west.nl - west consulting b.v. –

patch.nooptions (1.05 KB)

patch.outgoingmail (368 Bytes)

patch.textareas (3.75 KB)

2

Arthur,
Thanks very much for the very detailed comments and questions.
I appreciate the time you put into this…

  • In the Search/Listing.html page:
    When you select Next page:
    Can’t locate object method “NextPage” via package “RT::Tickets” at
    /vol/RT-2.beta-test/lib/RT/Interface/Web.pm line 232, chunk 377.
    When you try to update search criteria
    Can’t locate object method “OrderBy” via package “RT::Tickets”

Bring yourself up to the latest 1.3.5? version. this should be happier.

  • If a user is not privileged his/her uid does not show in any lists
    (Admin/Users/index.html or Admin/Groups/Members.html)

That’s correct. non-privileged users can’t be granted any rights.
Non-privileged users are folks who are only requestors or ccs…

  • In the SelfService stuff the Preferences link does not work
    (SelfService/Prefs.html does not exist) (what is the SelfService and
    unprivileged stuff for anyway or did i miss some documentation?) (The
    SelfService stuff does not display any requests even if I own them)

SelfService is so requestors can look at their tickets online. nonprivileged
folks can’t own tickets…all they can do is look at the selfservice area.
this is the long-promised ‘web ui for requestors’ and yeah, preferences
hasnt’ been done yet

  • User interface:
    We currently use RT1 for handling customer requests. Is it possible to
    shield RT2 so that different customers (who would be in different groups)
    will only be able to see their own information? We don’t think our
    customers need to known all our customers and their users. Also the list
    of users in RT2 should not be public in all setups. Can this be
    implemented with a ShowAdministration right (or something equivalent)?

I think this is ‘SelfService’ that I mentioned above :slight_smile:

  • Typo: (might be in more places)
    Admin/Global/Scrips.html
    Add a scrip which will apply to all queues:
    ^t

no. they’re called scrips. Scrips are sort of a cross between scripts and
subscriptions

  • Error in outgoing mail:
    If no To: header would be filled in an “Undisclosed recipients” is
    used. Our sendmail says this is an unknown user.
    See patch.outgoingmail

I’ll take a look. I’m pretty sure what we’re doing is RFC compliant.
what sendmail are you using?

  • In the main screen (home) the “Tickets I requested”
    window is always empty somehow…

even if you request some tickets?

  • If you update information on a user the signature is appended with a extra
    new line (probably browser specific still using Netscape 4.75 on Solaris)
    For this and other text areas see patch.textareas.

I’ll take a look

  • The installed programs in bin have the location of perl hard coded to
    /usr/bin/perl (not modified during install).

urk. thanks.

  • The CVS directories are installed as well (and the distribution version
    does not contain a useful CVS/Root file. You could consider using the
    pserver CVS/Root here.)

there’s the small problem that enough of the files get munged and the perl
files get ‘installed’ by a makemaker built makefile that I’d probably
be better off stripping them out…

  • In the modify ticket basics (Ticket/Modify.html) there are ‘-’ options for
    queues and status that should not be there.
    See patch.nooptions.
    This probably modifies all status and queue selectors but I couldn’t find
    any place where that would be incorrect and couldn’t think of one either.

Actually, the ‘no value’ items are kind of critical for a lot of things like
searching. and the web ui should do the right thing if you pick the null options…

  • Just something I think is a little annoying is that almost all files have
    their execute bit set (including README). If you remove the execute bits in
    the CVS repository this can be fixed and instead of chmod 0755 you could
    used chmod u+rwX,go-w,go+rX in the install (is a bit longer but does not
    set unneeded x bits and is more readable).

I’ll take a look. thanks.

  • When I receive a notification email the “Requestors” field is set to
    ARRAY(0xfe1918) (instead of a list of requestors) in the template.

I’ll take a look

  • Shouldn’t a “Take” result in a status change to “open”?

Not necessarily.

  • What is exactly the difference between the xxAsComment and xx actions?

hrm. that’s a bit confusing. The difference is that the queue return address
is set to the ‘comment’ adddress for the AsComment methods. suggestions
for a better name?

  • What is exactly the difference between CC and Administrative CC?

AdministrativeCcs can be granted different rights, such as ‘ShowComments’

  • When a request is created by the mail interface and the mail contains a CC:
    this is not entered into the CC field of the request. Not sure this is
    needed though.

I’ll take a look. that’s certainly something we’d talked about doing
a while ago.

  • Is the next diagram correct for describing mail actions?
    1 Requestors
    2 Owner
    3 CC in ticket
    4 CC in queue (via Admin->Queues->People)
    5 ACC in ticket
    6 ACC in queue (via Admin->Queues->People)
    | 1 | 2 | 3 | 4 | 5 | 6 |
    NotifyRequestor | + | - | - | - | - | - |
    NotifyOwnerAsComment | - | + | - | - | - | - |
    NotifyOwner | - | + | - | - | - | - |
    NotifyAdminWatchersAsComment | - | - | - | - | + | + |
    NotifyAdminWatchers | - | - | - | - | + | + |
    NotifyRequestorAndCcsAsComment| + | - | + | + | ? | ? |
    NotifyRequestorAndCcs | + | - | + | + | ? | ? |
    NotifyAllWatchersAsComment | ? | ? | + | + | + | + |
    NotifyAllWatchers | ? | ? | + | + | + | + |

I think so. the ?s should be -s

  • When using the [Users] and [Groups] links in the [Administration] menu
    there is no easy way to select a different user when a user (or group) is
    already selected. The [Users] and [Groups] links don’t work then. This is
    annoying.

That got fixed in ~1.3.51

Ok that’s it for now. I’ll try a newer version soon and see what problems I
run in to. RT2 looks very promising.

– arthur de jong - arthur@west.nl - west consulting b.v. –

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

As I sit here alone looking at green text on a laptop in a mostly bare room listening
to loud music wearing all black, I realize that that it is much less cool in real life :slight_smile:
–Richard Tibbetts

3
  • Typo: (might be in more places)
    Admin/Global/Scrips.html
    Add a scrip which will apply to all queues:
    ^t

no. they’re called scrips. Scrips are sort of a cross between scripts and
subscriptions

It’s probably too late to change this, but the terminology is misleading.
All of my users parse them as “scripts”.

  • Error in outgoing mail:
    If no To: header would be filled in an “Undisclosed recipients” is
    used. Our sendmail says this is an unknown user.
    See patch.outgoingmail

I’ll take a look. I’m pretty sure what we’re doing is RFC compliant.

It may be “RFC compliant” but sendmail’s “-t” switch doesn’t know that.
What happens is that when you ask sendmail to parse the message To: line
for recipient addresses, it copies “Undisclosed recipients” to the
envelope To:.

You could remove setting the To: header to “Undisclosed recipients”, but
the real problem is the hardcoded sendmail command line. You should use
Mail::Internet and Mail::Mailer.

what sendmail are you using?

  • In the main screen (home) the “Tickets I requested”
    window is always empty somehow…

even if you request some tickets?

ivan@rootwood:~/RT/work/rt/webrt/Elements$ cvs diff -u -r1.5 -r1.6
MyRequests
Index: MyRequests
RCS file: /proj/maps/cvsroot/rt/webrt/Elements/MyRequests,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
— MyRequests 2001/03/07 10:53:05 1.5
+++ MyRequests 2001/03/09 23:16:45 1.6
@@ -51,7 +51,7 @@

my $MyTickets;
$MyTickets = new RT::Tickets ($session{‘CurrentUser’});
-$MyTickets->LimitRequestor(VALUE => $session{‘CurrentUser’}->Id);
+$MyTickets->LimitRequestor(VALUE =>
$session{‘CurrentUser’}->EmailAddress);
$MyTickets->LimitStatus(VALUE => “open”);
$MyTickets->LimitStatus(VALUE => “new”);
</%INIT>

meow
_ivan

4

It may be “RFC compliant” but sendmail’s “-t” switch doesn’t know that.
What happens is that when you ask sendmail to parse the message To: line
for recipient addresses, it copies “Undisclosed recipients” to the
envelope To:.

Urk. sigh

You could remove setting the To: header to “Undisclosed recipients”, but
the real problem is the hardcoded sendmail command line. You should use
Mail::Internet and Mail::Mailer.

Actually, we do, by way of MIME::Entity.

ivan@rootwood:~/RT/work/rt/webrt/Elements$ cvs diff -u -r1.5 -r1.6
MyRequests

Cool, thanks. will be in the next release. which should happen late tonight
or tomorrow.

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

. . . when not in doubt, get in doubt. – Old Discordian Proveb

5

The whole Search/Listing.html seems to be broken as of 1-3-57 (method
RedoSearch cannot be found in any source file outside of Listing.html). Maybe
some lib files are missing in the distribution? The whole 1-3-57 release
seems to have more problems than 1-3-49_01. A lot of system errors mainly
regarding missing methods.
That sounds to me like you either didn’t restart apache or you didn’t upgrade
to the latest DBIx::SearchBuilder. I can’t replicate that here.

Oops my fault. I forgot to do make testdeps on installation, sorry.

On the Admin/Users page there’s a “find users who…”. The thing about
nonprivileged users is that there are likely to be lots of them. you don’t
want them showing up in a list by default.

But there should be a way to list them all, right?

– arthur de jong - arthur@west.nl - west consulting b.v. –

6

On the Admin/Users page there’s a “find users who…”. The thing about
nonprivileged users is that there are likely to be lots of them. you don’t
want them showing up in a list by default.

But there should be a way to list them all, right?

nod A better UI for this is likely to not happen before 2.0, though it
is something that needs to happen.

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

After all, it’s not every day you meet up with an evil power
-M. Bulgakov

7

I modified several files (Ticket/Elements/EditPeople,
Ticket/Elements/EditWatchers, Ticket/Elements/ShowPeople and
Ticket/Update.html) to show the Cc’s and AdminCc’s for the queue alongside
the list of Cc’s and AdminCc’s for the ticket. I did a grep on all the
files and I think these are all the files displaying this info. See
attached files for my version of the file.

Oops I thought that join was smart but not smart enough.

join(", ",($Ticket->CcAsString,$Ticket->QueueObj->CcAsString))

should be:

join(", ",@{$Ticket->Cc->Emails},@{$Ticket->QueueObj->Cc->Emails})

unless someone known a better neat perl construct. Sorry about that. We might
even introduce sorting or filtering out of double addresses?

New and improved Ticket/Elements/ShowPeople, Ticket/Update.html and patchfile
included. Sorry about that.

– arthur de jong - arthur@west.nl - west consulting b.v. –

ShowPeople (359 Bytes)

Update.html (1.76 KB)

bigpatch2 (6.13 KB)

8

As promised more bug(fixes) and comments. I hope RT2 will be stable quick
so we can take it into production.

First of all my Date patch didn’t get through quite right. The patch for
editing dates was against two files and only one got partly through
resulting in wrong output. My Elements/SelectDate and
Ticket/Elements/EditDates files are attached.

I modified several files (Ticket/Elements/EditPeople,
Ticket/Elements/EditWatchers, Ticket/Elements/ShowPeople and
Ticket/Update.html) to show the Cc’s and AdminCc’s for the queue alongside
the list of Cc’s and AdminCc’s for the ticket. I did a grep on all the
files and I think these are all the files displaying this info. See
attached files for my version of the file.

The “Open tickets (from listing) in seperate window” and “Display each
ticket in its own window” in the Preferences do not seem to work. When I
select a checkbox and press “Submit” the value is not saved. The checkboxes
in the resulting page are not selected and I cannot detect any change in
function of RT (on which page should there be any change anyway?).

On Administration->Queues->Watchers (Admin/Queues/People.html) there is a
link per user to Admin/Users/Display.html that does not exist. Shouldn’t
that be Admin/Users/Modify.html?

A problem: There is no easy way to add an email address as Cc to a ticket
(using the Web interface) when that email address does not belong to a
registered user.

All the modifications listed above can also be found in 1 patchfile
(bigpatch).

– arthur de jong - arthur@west.nl - west consulting b.v. –

SelectDate (610 Bytes)

EditDates (774 Bytes)

EditPeople (910 Bytes)

EditWatchers (1.31 KB)

ShowPeople (351 Bytes)

Update.html (1.75 KB)

bigpatch (4.96 KB)

9

As promised more bug(fixes) and comments. I hope RT2 will be stable quick
so we can take it into production.

Look for more mail from me on that tomorrow or thursday.

First of all my Date patch didn’t get through quite right. The patch for
editing dates was against two files and only one got partly through
resulting in wrong output. My Elements/SelectDate and
Ticket/Elements/EditDates files are attached.

Actually, your original patch worked in a way that wasn’t quite how
I wanted to make it work. The “fill in date” boxes should be blank,
rather than containing the existing date, because, in general, it’s going
to be harder for a user to enter a new date. (The range of acceptable
dates that can be entered is very very wide. you don’t have to keep things in
ISO format. Try typing “next tuesday” into a date selector).

I modified several files (Ticket/Elements/EditPeople,
Ticket/Elements/EditWatchers, Ticket/Elements/ShowPeople and
Ticket/Update.html) to show the Cc’s and AdminCc’s for the queue alongside
the list of Cc’s and AdminCc’s for the ticket. I did a grep on all the
files and I think these are all the files displaying this info. See
attached files for my version of the file.

I’ll probably take a variant of this into the core release. I want
to make sure that queue and ticket watchers are kept very seperate
and that people always understand who is what sort of watcher.
But I appreciate the need to better inform the user about queue watchers.

The “Open tickets (from listing) in seperate window” and “Display each
ticket in its own window” in the Preferences do not seem to work. When I
select a checkbox and press “Submit” the value is not saved. The checkboxes
in the resulting page are not selected and I cannot detect any change in
function of RT (on which page should there be any change anyway?).

nod That was some code tobias prototyped that never got implemented.
I suspect that if it looks like it’s going to take me
more than 30 minutes to get all happy, it’s going to get yanked
until it can be done right for 2.2

On Administration->Queues->Watchers (Admin/Queues/People.html) there is a
link per user to Admin/Users/Display.html that does not exist. Shouldn’t
that be Admin/Users/Modify.html?

Well, long term, there should be a “Display” page there too, but for the short
term, yeah, it should link to Modify.

A problem: There is no easy way to add an email address as Cc to a ticket
(using the Web interface) when that email address does not belong to a
registered user.

Known issue. Ticket # 39 http://fsck.com/rt2/Ticket/Display.html?id=39
(see http://fsck.com/rt2/NoAuth/Buglist.html)

All the modifications listed above can also be found in 1 patchfile
(bigpatch).

While I’d rather have a “jumbo” patch than no patch at all, if you’re able
to do seperate patches for each feature, that would be even cooler. Sometimes,
different features have different priorities for getting into the codebase and
it’s helpful to be able to pull in the really high-priority stuff right away.

         Thanks for your work on this,
         Jesse

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

There are no supercomputer applications that are solvable that cannot be solved
in finite time using a fucking TRS-80 with approprite disk/tape drives. Zero.
-Tanj

10

First of all my Date patch didn’t get through quite right. The patch for
editing dates was against two files and only one got partly through
resulting in wrong output. My Elements/SelectDate and
Ticket/Elements/EditDates files are attached.
Actually, your original patch worked in a way that wasn’t quite how
I wanted to make it work. The “fill in date” boxes should be blank,
rather than containing the existing date, because, in general, it’s going
to be harder for a user to enter a new date. (The range of acceptable
dates that can be entered is very very wide. you don’t have to keep things in
ISO format. Try typing “next tuesday” into a date selector).

There is also a patch in there that fixes a nasty bug (but if the code isn’t used
it does not show). The month was incremented twice and the year was added 1900
twice.

I modified several files (Ticket/Elements/EditPeople,
Ticket/Elements/EditWatchers, Ticket/Elements/ShowPeople and
Ticket/Update.html) to show the Cc’s and AdminCc’s for the queue alongside
the list of Cc’s and AdminCc’s for the ticket. I did a grep on all the
files and I think these are all the files displaying this info. See
attached files for my version of the file.
I’ll probably take a variant of this into the core release. I want
to make sure that queue and ticket watchers are kept very seperate
and that people always understand who is what sort of watcher.
But I appreciate the need to better inform the user about queue watchers.

The edit people link shows the different watchers in the following groups:
Requestors, Cc, Administrative Cc, Queue Cc and Queue Admin Cc. The last two are
not deletable in the screen. On all the other screens (where CC and Admin CC are
just listed) no distinction is made. You could always show Queue watchers in a
different color (not shure that would make things clearer though).

While I’d rather have a “jumbo” patch than no patch at all, if you’re able
to do seperate patches for each feature, that would be even cooler. Sometimes,
different features have different priorities for getting into the codebase and
it’s helpful to be able to pull in the really high-priority stuff right away.

Ok two features (date stuff and queue watchers stuff) in two patches (dates.patch
and watchers.patch).

– arthur de jong - arthur@west.nl - west consulting b.v. –

dates.patch (1.89 KB)

watchers.patch (3.08 KB)

11

A problem: There is no easy way to add an email address as Cc to a ticket
(using the Web interface) when that email address does not belong to a
registered user.

My RT2 has edit instead of display of Requestor, Cc and AdminCc on
Ticket/Update.html. It’s separated UI-wise from the transaction
properties and labeled as ticket-global. It seems a natural part of our
workflow here that we might want to add or remove a Cc: or Requestor when
composing a reply or comment. Is there interest in a patch for
RT2-proper?

meow
_ivan

12

The “Open tickets (from listing) in seperate window” and “Display each
ticket in its own window” in the Preferences do not seem to work. When I
select a checkbox and press “Submit” the value is not saved. The checkboxes
in the resulting page are not selected and I cannot detect any change in
function of RT (on which page should there be any change anyway?).

nod That was some code tobias prototyped that never got implemented.
I suspect that if it looks like it’s going to take me
more than 30 minutes to get all happy, it’s going to get yanked
until it can be done right for 2.2

it looks like it tries to update stuff in the users Apache::Session
session, which won’t work right at all; users are expecting these to be
persistant. I yanked it for my first release and as you know I’m waiting
for your notes on how you’d like user preferences implemented. I also
added a warning about ACLs if a user who isn’t permitted to `ModifySelf’
tries to edit their signature, as “I can’t edit my .signature” became my
#1 FAQ.

meow
_ivan

13

Interesting. That sounds quite useful. I’d at least like to see how it
looks and feels :slight_smile:

    -jOn Fri, Mar 30, 2001 at 04:37:05AM -0800, ivan wrote:

On Mon, Mar 26, 2001 at 04:16:49PM +0200, Arthur de Jong wrote:

A problem: There is no easy way to add an email address as Cc to a ticket
(using the Web interface) when that email address does not belong to a
registered user.

My RT2 has edit instead of display of Requestor, Cc and AdminCc on
Ticket/Update.html. It’s separated UI-wise from the transaction
properties and labeled as ticket-global. It seems a natural part of our
workflow here that we might want to add or remove a Cc: or Requestor when
composing a reply or comment. Is there interest in a patch for
RT2-proper?

–
meow
_ivan

Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – root@eruditorum.org – jesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

“That package looks like what I wanted, but the site was down today,
so I decided to reimplement it in Perl.”
-me