rt/docs/design_docs/evil_plans

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