Configurable Access On Value Transitions?

[MattyT]

Problem
-------

( Configurable Access Policy Proposal )

> <joel> So what I am permitted to do would never vary by what
> state something is in... only by who I am and what it is??

This is a good time to discuss what we are planning to do here.

The issue is one of "transitions" between field values, and whether you
can define a separate group that can do each (ie have different roles
for different transitions).

A corollary of being able to set a group on a transition is that you can
prevent it all together.

Plans
-----

Now, this is definitely the plan for customised statuses, ie there is a
role from status A to status B.  To see its usefulness, consider
RESOLVED->VERIFIED only doable by the QA contact.

The keywords field requires you to bend your mind a little bit.  I
reject the notion we should have a role for the keywords field. 
Keywords isn't really a "field".

In a very real sense, each keyword is a field unto itself,and deserves a
separate policy.  As such, a keyword is a boolean field, having two
transitions, and therefore two roles, add and remove.  Hence it's not
suprising to find bug #167013.

This is really needed, for approval keywords and so on.

However it has not been planned for other fields.

For resolutions, I considered it, but it definitely is not a part of
custres.  That is, only certainly people can use certain resolutions.  A
further complication is certain resolutions might only be possible from
certain statuses (eg resolution NOINFO from status NEEDINFO).  But that
complication is perhaps overkill.

This is useful I believe, for example only certain people would be
allowed to make a NOTWORTHIT decision.  But I don't think it's high
priority in any sense.

But what about other fields?

Issues
------

Other fields - is it useful, is it needed?  Consider especially that we
will probably be getting customised fields sometime in the short- to
mid-term, so new possibilities arise.

If we consider there to be no good reason to do it now, what problems
might it cause if we do a per-field implementation of access policies
and want to change to per-transition later?

Transition Roles Vs. Product Specifism
--------------------------------------

Yesterday I mentioned the fact that each field should have a can-change
role, for _each_ product.  The Mozilla access policy and Bugzilla access
policy would be different, for example for Target Milestone.  While
assignee and so on can change in each case, a different group can also
do it in each case (Mozilla - managers, drivers, Bugzilla - me, dave).

But what if we have transition roles on non-product specific fields?

For status, it's problematic.  Perhaps status should be
product-specific, but it isn't at the moment.  And that raises the
question - how could we have transition roles AND product specifism?

- Do we make it so there is a different set of transition roles for each
product, meaning the transitions are product specific yet the values
aren't?

- Do we reject product specificism for just the status field, in essence
giving a slight regression over a per-field system?

- Do we keep both a product-specific per-field role and global
transition role, and say you can do the transition if you can do the
transition (determined product specific) and change the field
(determined globally)?  Urgh.

The other field we're doing transitions on, keywords, is a lot easier
however.  While there aren't product-specific keywords yet, you can
essentially have them by convention.  If you want a different access
policy for a keyword in different products, split into different
keywords.

If we have transition roles on general non-product-specific fields, the
problem becomes worse.  We can't do without product-specific access
policies.

Product-specific fields are less of a problem.  The transitions would
obviously product specific.

And finally, does all this mean we should make the changes to let all
fields be product-specific (and -inspecific if the admin wants), before
doing transition roles, including for status?  I suppose the transition
role feature could (and maybe should) be dropped off the initial
customised statuses patch.

If anyone wants details on what I think about making all fields product
specific, how we can implement this, how we can make it flexible, and
how we can make it easily administerable, let me know and I'll post
another message.

Implementation
--------------

Even if we nix general transition roles, we need to consider an
implementation for statuses.

The admin only has to turn on transition roles if they want, this would
prevent overly complicating the administration side as well as draining
performance, as you need to load in allowable transitions.

There are two possibilities for implementation I see.  The first is to
enumerate all the transitions.  This gives us 2^N possibilities for
fields using transition roles, although disallowed possibilities don't
need to have records.

As well as the record space, this implementation has the disadvantage
that total enumeration of transitions is only possible for enumeration
type fields.

The second possibility for implementation is a match-rule chain
implementation, like mail filters or firewall setup.  This is a
sequential list of rules, where once a rule-condition is matched, we get
the result from the rule and quit.

Because the records are ordered, we can have rules to match transitions
like X -> Anything.  If the records were not ordered, we would need to
make sure the transitions were distinct.

This can save space and make administration easier.  It also allows
transitions on non-enumeration fields, for example regexp matches on
text fields.

A disadvantage is that you need to have UI and code for adding, removing
and reordering rules, which could have been avoided in the first
implementation by displaying everything.

Another is you need to maintain "sortkeys" on the database to keep them
in order, and inserting rules in the middle can be tricky.  Anyone who
suggests storage outside of the database will be severely flogged.

Further, we might consider allow transition rules of the type
value-group-> value-group, where an administrator can group values
together.  This might sound like overkill, but we may well implement
value groups (with inheritance) as a part of an "every field can be
product-specific or -inspecific" implementation.

-- 
         Matthew Tuck: Software Developer & All-Round Nice Guy        
 My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award
1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic
         Emperor 1998 Released From Smith Psychiatric Hospital