diff options
Diffstat (limited to 'rt/docs/design_docs/evil_plans')
| -rw-r--r-- | rt/docs/design_docs/evil_plans | 162 |
1 files changed, 0 insertions, 162 deletions
diff --git a/rt/docs/design_docs/evil_plans b/rt/docs/design_docs/evil_plans deleted file mode 100644 index 5b5cc58..0000000 --- a/rt/docs/design_docs/evil_plans +++ /dev/null @@ -1,162 +0,0 @@ -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. |