[rt-devel] Thoughts on 2.2

[Jay Kramer]

> Core
>
> Should Make "Owner" a watcher type, rather than a special ticket
attribute,
> under the hood.  This wins for ACL and code consistency reasons.

    I like this ;)  It would make programming custom stuff easier than it is
now..

> Web UI
>
> Should New "Tools" top level menu

    What would this entail?


> Must Saveable user preferences.

    Good! ;)

> should Saveable user searches.

    This is really good..  I find myself looking for the same things over
and over..

> Custom fields
>
> Should String and multi-string custom fields.

    I like this...  lots of potential :)  Is this going to be a custom
"keyword: value" pair?  where the keyword is set by the admin, and you can
fill in a custom string value for that keyword?

> Nice Default values
> Nice Required values

    These are really useful too

> Nice Make custom fields apply to an enumerated list of queues,
> rather than just one.

    Does this pertain to moving tickets from queue to queue and losing
custom fields?  This should be an option when you move a ticket, somethign
like "retain custom fields or drop them (y/n)?"

> Must Full fastcgi support.

    Would make a lot of people happy.... :)

> Installation
>
> Should Better FSSTD conformance:
> bins in /bin
> admin tools in /sbin (does this include rtadmin?)
> ephemeral data in /var
> rename config file
> force local RT search path?

    Make most of these just symlinks though to the actual RT install
directory (or even hard links, but I'd prefer the other)..  Also, put the
config file(s) in /etc/rt or something ;)  That allows for future expansion
in case you would want a separate config file (say for the mail gateway or
something)..  that way you go to one place for most of the configs on your
system..  again, symlinks would suffice ;)

> Mail gateway
>
> must Integrate gpg-authenticated command-by-mail mode

    If you integrate, could you possible make it so there is a config option
to NOT use gpg and still allow the comamnd by mail to work?  reason being is
some of this is an 'internal only, by trusted people' thing, and the general
public does nto even know about it.  That way the less techy users can still
do the command by mail stuff without the complexity of GPG, without a lot of
training.. (I know, GPG is there for security and user identification, but
if you could do it just by the source address as well and config option hwo
it works..  would be EXCELLENT)


> Core
>
> should Use apache logging, if available
> should Use syslog, if available.
> should Mail user new password, as an Action, so it can be invoked either
> as a scripaction or from the web ui.

    I like this..  The logging in RT has needed work for a while, and I
actually started to make it use syslog once, but then gave up in the middle
because of time constraints..  And, the mailing of passwords to users is a
good thing..  If you do this, you may want to take a look at setting
"default groups" list, and a default settings for the user to have on
creation (like allow an admin to set "is privledged user" on creation)

>
>
> Web Services Framework
>
> Should Expose an API to create a ticket by HTTP posting an XML document.
> Should  Provide an RSS feed to display tickets matching certain criteria
> Nice Allow ticket updates via the web ui
> Nice Export full ticket metadata and history as XML

    Cool ;)  thats all I can say!

> Note: I currently favor the REST philosophy that GET and POST to specific,
> defined URLs provides everything one needs to build comprehensive
> web services without the massive added complexity of a SOAP or XML-RPC
> framework.

    Agreed...

> ACLs:
>
> Wish New ACL primitives for:
>
> List all users who have right "FOO" on object "BAR"
> List all rights user "BAZ" has for object "BAR"
> List all objects for which user "BAR" has right "FOO"

    Also maybe a NOT for ACL's, so you can negate a specific ACL for a
specific item.  That way you can set acl's to be general and then restrict
them in areas you need to (a specific queue for example)..


Jay