-Current planned 2.2 feature list. subject to change.
-
-
-Core
-
-
-
-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.
-
- The ideal implementation would be "saveable user metadata",
- including things like "Alternate Email Addresses". To
- do this right, not all user metadata would be directly
- editable by the user who has "ModifySelf" it may be that
- this is a "system" datastore that gets accessed by various
- functions, some of which the user has access to modify and
- some of which only the system does.
-
- API: Set field "FOO" to value "BAR" for user BAZ
- What values does field "FOO" have for user BAZ?
- Clear all values of "FOO" for user BAZ
- What users have value "BAR" for field "FOO"
-
- Example usages:
-
- What users have the alternative email address matching
- "boo@fsck.com"
- What custom searches does user BAZ have defined?
- What is baz's default queue?
-
- Actually, I feel a little sketchy about Alternative Email
- Addresses in there. I'm not quite sure why yet.
-
- The same would really be useful for queues. Damn it. I think
- I want a registry.
-
-
-
-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
-
-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
-
-
-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. Sadly, the world doesn't agree with me
-
-
-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"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-For the near future:
-
- Use case:
- Jesse wants to get notified of all tickets in queue 'RT Bugs'
- with a severity of 'critical' and also have a requestor whcih matches 'fsck.com'.
- I'm not sure this is the best idea.
-
-
- Site admins define a number of subscriptions and can sign up individual
- users, groups or metagroups to get mail on that subscription.
-
- Basically, an admin would define "On Condition, notify as comment with
- template _template_"
-
- There would be a new table called "subscriptions"(?) that would have
- the structure:
-
- id
- ScripId
- PrincipalType ENUM: User, Group, Owner, Requestors, AdminCcs, Ccs
- PrincipalId -- UserId or GroupId. For Owner, Requestors, AdminCcs, Ccs, it doesn't really make a lick of difference.
projects / freeside.git / blobdiff