[rt-devel] RT2 bugs and comments

Jesse jesse at fsck.com
Mon Mar 19 13:32:00 EST 2001


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


On Mon, Mar 19, 2001 at 02:21:04PM +0100, Arthur de Jong wrote:
> * 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, <GEN49> 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 :)

> * 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 at west.nl - west consulting b.v. --

-- 
jesse reed vincent -- root at eruditorum.org -- jesse at 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 :)
			--Richard Tibbetts
	




More information about the Rt-devel mailing list