rt/docs/design_docs/evil_plans

   1 Current planned 2.2 feature list. subject to change.
   2
   3
   4 Core
   5
   6 Should  Make "Owner" a watcher type, rather than a special ticket attribute,
   7         under the hood.  This wins for ACL and code consistency reasons.
   8
   9 Web UI
  10
  11 Should  New "Tools" top level menu
  12 Should          "This week in RT" at a glance.
  13 Nice            "RT Stats" overview.
  14 Nice    recent and favorite items
  15
  16
  17 per-user configuration
  18
  19 Must            Saveable user preferences.
  20
  21                 The ideal implementation would be "saveable user metadata",
  22                 including things like "Alternate Email Addresses".  To
  23                 do this right, not all user metadata would be directly
  24                 editable by the user who has "ModifySelf"  it may be that
  25                 this is a "system" datastore that gets accessed by various
  26                 functions, some of which the user has access to modify and
  27                 some of which only the system does.
  28
  29                 API:    Set field "FOO" to value "BAR" for user BAZ
  30                         What values does field "FOO" have for user BAZ?
  31                         Clear all values of "FOO" for user BAZ
  32                         What users have value "BAR" for field "FOO"
  33
  34                 Example usages:
  35
  36                         What users have the alternative email address matching
  37                         "boo@fsck.com"
  38                         What custom searches does user BAZ have defined?
  39                         What is baz's default queue?
  40
  41                 Actually, I feel a little sketchy about Alternative Email
  42                 Addresses in there. I'm not quite sure why yet.
  43
  44                 The same would really be useful for queues. Damn it. I think
  45                 I want a registry.
  46
  47
  48
  49 Searching
  50
  51 Must    Ability to define search result format.
  52 should  Saveable user searches.
  53 nice    Sharable searches.
  54
  55
  56 Scrips
  57
  58 must    Include more Conditions; at least those contributed so far
  59         that make sense in my grand scheme of things
  60
  61 should  The name should change to something that people don't think is
  62         spelled wrong.  ("I will not invent words\n" x 1000)
  63
  64 nice    Scrips could apply to a list of queues, rather than just one queue or
  65         all of them.
  66
  67
  68 Custom fields
  69
  70 Must    "KeywordSelects" become "Custom Fields"
  71 Should  String and multi-string custom fields.
  72 Nice    Date custom fields
  73 Nice    Some way to order and group custom fields.
  74 Nice    Default values
  75 Nice    Required values
  76 Nice    Make custom fields apply to an enumerated list of queues,
  77         rather than just one.
  78
  79
  80 Web infrastructure
  81
  82 Must    Full fastcgi support.
  83
  84
  85 Installation
  86
  87 Should  Better FSSTD conformance:
  88                 bins in /bin
  89                 admin tools in /sbin (does this include rtadmin?)
  90                 ephemeral data in /var
  91                 rename config file
  92                 force local RT search path?
  93
  94 Mail gateway
  95
  96 must    Integrate gpg-authenticated command-by-mail mode
  97
  98
  99
 100 Core
 101
 102 should  Use apache logging, if available
 103 should  Use syslog, if available.
 104 should  Mail user new password, as an Action, so it can be invoked either
 105         as a scripaction or from the web ui.
 106
 107
 108
 109 Web Services Framework
 110
 111 Should  Expose an API to create a ticket by HTTP posting an XML document.
 112 Should  Provide an RSS feed to display tickets matching certain criteria
 113 Nice    Allow ticket updates via the web ui
 114 Nice    Export full ticket metadata and history as XML
 115
 116 Note:   I currently favor the REST philosophy that GET and POST to specific,
 117         defined URLs provides everything one needs to build comprehensive
 118         web services without the massive added complexity of a SOAP or XML-RPC
 119         framework.
 120
 121
 122 ACLs:
 123
 124 Wish    New ACL primitives for:
 125
 126                 List all users who have right "FOO" on object "BAR"
 127                 List all rights user "BAZ" has for object "BAR"
 128                 List all objects for which user "BAR" has right "FOO"
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147 For the near future:
 148
 149         Use case:
 150                 Jesse wants to get notified of all tickets in queue 'RT Bugs'
 151                 with a severity of 'critical' and also have a requestor whcih matches 'fsck.com'.
 152                 I'm not sure this is the best idea.
 153
 154
 155         Site admins define a number of subscriptions and can sign up individual
 156         users, groups or metagroups to get mail on that subscription.
 157
 158         Basically, an admin would define "On Condition, notify as comment with
 159         template _template_"
 160
 161         There would be a new table called "subscriptions"(?) that would have
 162         the structure:
 163
 164                 id
 165                 ScripId
 166                 PrincipalType  ENUM: User, Group, Owner, Requestors, AdminCcs, Ccs
 167                 PrincipalId --  UserId or GroupId.  For Owner, Requestors, AdminCcs, Ccs, it doesn't really make a lick of difference.