Thoughts on 2.2

RT Developers
1

Here’s the current state of my thinking on 2.2. This is all subject to change,
unless there’s a contractual obligation involved.

This is the “big” stuff. there are a bunch of small tweaks and cleanups.

I know that Canned replies aren’t on the list right now. That functionality,
when it happens, will probably be a drop-in addition using some other
cool stuff I’m working on.

Core

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

Web UI

Should New “Tools” top level menu
Should “This week in RT” at a glance.
Nice “RT Stats” overview.
Nice recent and favorite items

per-user configuration

Must Saveable user preferences.

Searching

Must Ability to define search result format.
should Saveable user searches.
nice Sharable searches.

Scrips

must Include more Conditions; at least those contributed so far
that make sense in my grand scheme of things

should The name should change to something that people don’t think is
spelled wrong. (“I will not invent words\n” x 1000)

nice Scrips could apply to a list of queues, rather than just one queue or
all of them.

Custom fields

Must “KeywordSelects” become “Custom Fields”
Should String and multi-string custom fields.
Nice Date custom fields
Nice Some way to order and group custom fields.
Nice Default values
Nice Required values
Nice Make custom fields apply to an enumerated list of queues,
rather than just one.

Web infrastructure

Must Full fastcgi support.

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?

Mail gateway

must Integrate gpg-authenticated command-by-mail mode

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.

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

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.

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"

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

2

Wishlist-mode: on :slight_smile:

Useful stuff in the scrips (or whatever it will be called)
would be the possibility to automatically give and set cc:s
based on the creator of a ticket. Proably a good way could be
to use a regexp: If creator is *@foo.com assign to
user1@myplace.com and add salesguy1@myplace.com to the cc list.

Could probably be applied to other aspects of the ticket too…

regards,
/Anders Klint

PS. If someone has implemented this, it’s OK t flame me as long as
you provide a pointer. :slight_smile:
(I’m trying to keep an eye on this list but not reading everything
in detail)

3

JV> Web Services Framework

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

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

Wishlist: on.

Consider using SOAP instead of just XML documents. Many languages have
very convinent and transparent support for SOAP (SOAP::Lite rocks in
Perl). I suspect that it will be much more easier to write clients
using SOAP interface compating to raw XML inteface.

Ofcource as RT author you should understand internals better than me
:slight_smile: But at first look it seems to me that SOAP interface should be
easier to implement (again SOAP::Lite rocks :slight_smile: ).

| Ilya Martynov (http://martynov.org/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/) |

4

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 :wink: 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 :wink:

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

5 
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)…

Sadly, there’s just about no chance this is going to happen in the forseeable
future, due to the level of complexity it will add.

-j

Jay

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

6

m_ilya@agava.com wrote a 1.5KB message. i replied …

JV> Web Services Framework

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

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

Wishlist: on.

Consider using SOAP instead of just XML documents. Many languages have
very convinent and transparent support for SOAP (SOAP::Lite rocks in
Perl). I suspect that it will be much more easier to write clients
using SOAP interface compating to raw XML inteface.

I’m definately interested in testing/implementing SOAP ticket
creating/modification under RT 2 (with SOAP::Lite).

(Not yet having much SOAP exp) I don’t suppose it would be as simple
as exporting the RT API via HTTP dispatch ?

curious,

_MIchael.

Michael A. Jastremski Openphoto.net/mike
Megaglobal Corporation, Network Defense Megaglobal.net
Philadelphia, PA, USA Westphila.net

7

+1 to this. I agree that “massive added complexity” comes to mind when
you look at soap and xml-rpc, but you as an author are insulated from
that, and everyone who digs this type of transaction will expect the
standard. “Why should I have to write a custom xml document handler for
<language.x> to use the web service interface?”, etc.

Marc Hedlund
e: marc at precipice dot orgOn 10 Oct 2001, Ilya Martynov wrote:

JV> Web Services Framework

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

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

Wishlist: on.

Consider using SOAP instead of just XML documents. Many languages have
very convinent and transparent support for SOAP (SOAP::Lite rocks in
Perl). I suspect that it will be much more easier to write clients
using SOAP interface compating to raw XML inteface.

Ofcource as RT author you should understand internals better than me
:slight_smile: But at first look it seems to me that SOAP interface should be
easier to implement (again SOAP::Lite rocks :slight_smile: ).

–
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/) |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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