110947 - Fine grained bug security system.

Status: RESOLVED DUPLICATE of bug 189627

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Matthew Tuck [:CodeMachine]]

Currently Bugzilla supports two levels of bug security, editbugs and no
editbugs.  We need this to be more customisable.  It also needs to be
customisable on a product by product basis.  Mozilla and Bugzilla would have
different policies, for example.

There should be a list of policies.  Each policy has a list of products it
applies to.  As long as we're only dealing with products as to what decides what
policy to use, we should prohibit including the same product twice.

There is a "default" policy that applies if the product is not found.  It should
display the products it currently applies to.

Each policy works as follows:

This group can change all fields: [Bugzilla    ]

This group can also change the priority field: [none       ]
This group can also change the assignee field: [none       ]
...
This group can also change the severity field: [BugzillaHelpers]

This needs to wait until the groups rewrite.

We also need to decide how the privileged people on the report get to alter
these things.  Does the reporter get to change the severity automatically?  Does
the assignee get to change the milestone automatically, or do we prohibit
assigning to someone who doesn't have this authority?  Etc.

Comment 1

[Matthew Tuck [:CodeMachine]]

There also needs to be a bank of settings for each keyword, wherein there are
settings for being able to see the keyword, being able to add it and being able
to remove it.

Comment 2

[Matthew Tuck [:CodeMachine]]

Attachment: Simple mockup of what this might look like.

Comment 3

[Matthew Tuck [:CodeMachine]]

One point to note about the above mockup, is that there is the concept of
separate policies and giving them names.

The idea here is you can share a policy between products, while allowing
different policies for different products.

The tricky issue this raises is to what extent we want to be really fine
grained, ie within a "field".

For example, we probably want different access settings for each individual
keyword, attachment status, and status transition.

This is totally different from the per-product policies mentioned above and
would probably be difficult to integrate into it if we wanted.  We could
possibly integrate a default bank for new keywords, attstats or stattrans
though.

Keywords are currently global, so it possibly makes some sense to include this
in the policy, but I'm not sure it makes sense to have keywords be available
globally, not allow per-product usage, yet allow per-product access policies.

Attstats are currently per-product only, so defining them in a policy that is
reusable between products is not on either.

Stattrans aren't configurable yet, but when they are the above issues need to be
considered.

And do we want to be really fine grained on anything else, bearing in mind this
makes the policy potentially more complicated to define, as well as making the
policy code harder to implement?  For example, restricting certain resolutions
or severities to certain groups?

Comment 4

[Joel Peshkin]

Perhaps this should use rulesets like IPTABLES  ??

This way, a policy could apply to a single product or all products, etc...

Comment 5

[Dave Miller [:justdave]]

bug 189627 is essentially the same thing.  It's more recent, but has more
discussion on it, and more relavant to Bugzilla's current architecture.

*** This bug has been marked as a duplicate of 189627 ***

Comment 6

[Dave Miller [:justdave]]

clearing target on DUPLICATE/WONTFIX/INVALID/WORKSFORME so they'll show up as
untriaged if they get reopened.