Below, you’ll find a list of things we talked about in Pilsen. It’s really
still just notes at this point. It ranges from code style decisions
to blue-sky feature requests…
RT’s Scrip’s mechanism is quite powerful It needs additional documentation.
For example, we should explain how we can make the owner "so and so"
when a ticket in a particular queue is created and how to set the priority to
a given value based on the requestor’s email address.
It’s very important that sites be able to modify the RT web ui and core
code in such a way that their modifcations don’t prevent easy upgrades to
newer RT versions. To that end, we need to play with and document how
to put together multiple component roots and RT perl library paths.
Ideally, local versions of RT core libraries would be simple wrapper classes
which only override the functions the local site wants to modify.
Experimentation and documentation is called for.
Within the RT core code, methods which return an object of some type
should end in Obj. (IE a method that returns an RT::Ticket object might
be called “TicketObj”. $class->new is an exception to that rule.
As yet, we are undecided as to what the standard should be for
variables which hold an object reference.
TODO: [for 2.0]
When generating user accounts, RT should automatically assign them a password
and send them email. this should be configurable.
TODO: [probably for 2.1]
We need a plugin system to allow external authentication/user information
methods within RT. It must be possible for a site to use more than one
external authentication method. There should probably be a default, though.
RT2 will not have a “guest” account. The documentation needs to explain why.
RESOLUTION: [for 2.0]
Currently, the web autohandler inserts a header and a footer.