399084 - Remove the 'insidergroup' parameter

Status: NEW

(Bugzilla :: Administration, task, P1)

Description

[Frédéric Buclin]

Per our discussions at our last 2 Bugzilla meetings, this param should go away. It should be replaced by a system group.

Comment 1

[Alex Schuilenburg]

I am very concerned about this going away.  This is such a useful feature, but we don't want all our support staff to have system privileges just to be able to read and make private comments and attachments.  What system group are you proposing?

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> to read and make private comments and attachments.  What system group are you
> proposing?

A system group is a group which an admin cannot delete, such as admin, editbugs or canconfirm. So the idea is to have a hardcoded group named 'insidergroup' (any other name we may choose), and you would add users to this group to give them rights to add and read private attachments and comments. You can also easily give such privilege to a whole group thanks to group inheritance. So in no way are we going to drop this feature. We are simply moving this setting from the parameters page to the groups administration page.

Note to devs: we will have to be careful when removing this parameter. The current group chosen as the current insidergroup will have to be a member of the insidergroup system group. Not a big deal, though.

Comment 3

[Alex Schuilenburg]

That makes sense.  As long as 'insidergroup' is not given any additional privileges, I withdraw my objection.

Comment 4

[Frédéric Buclin]

Note that the new insidergroup (or maybe private_group would be a better name) should also be per-product, as we did with canconfirm, editbugs and editcomponents.

Comment 5

[Max Kanat-Alexander]

(In reply to comment #4)
> Note that the new insidergroup (or maybe private_group would be a better name)
> should also be per-product, as we did with canconfirm, editbugs and
> editcomponents.

  Yes, but that should happen in a separate bug.

Comment 6

[Frédéric Buclin]

This will be fixed by bug 299895.

Comment 7

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.