365767 - "Field Values" should have its own permission

Status: NEW

(Bugzilla :: Administration, task, P3)

Description

[timeless]

edit field values was something I could do before the upgrade. justdave agrees that it's something I should be able to do. it now requires admin privs which is not something I'm going to get.

either it needs to be its own group (preferably defaulting to inheriting editcomponents) or the restriction needs to be changed from admin to editcomponents (which is perfectly fine, I don't really think we need a new group).

Comment 1

[Frédéric Buclin]

We require admin privs since bug 353768, and justdave approved it.

Comment 2

[Max Kanat-Alexander]

I would agree that we can split this out into its own permission. For upstream, this would be a 3.2 change. However, you could probably apply the patch to bmo. It should be a fairly simple change.

Comment 3

[Gervase Markham [:gerv]]

Leaving aside timeless's particular relationship with b.m.o. for a moment, I think it's entirely reasonable to have editing field values be an admin thing. It's a global change to a fundamental part of how the app works. I don't think we need Yet Another Permission to manage.

Gerv

Comment 4

[timeless]

Attachment: something like this?

Comment 5

[Max Kanat-Alexander]

Comment on attachment 273369 [details] [diff] [review]
something like this?

At the least, you also have to update checksetup.pl to add the new group.

Comment 6

[Frédéric Buclin]

Why do we need a new priv again? Yet another group, and another priv to understand. How many different groups do we use by default in Bugzilla? This number is already impressive.

Comment 7

[timeless]

Attachment: inherit admin?

afaiu, the code already creates things that are listed in system groups. if you want to explicitly ensure that admin members inherit, we can do that...

Comment 8

[Max Kanat-Alexander]

Comment on attachment 273438 [details] [diff] [review]
inherit admin?

Bugzilla::Group->create automatically makes admins inherit, you don't have to do that manually.

But I didn't see you add it to SYSTEM_GROUPS.

Also, I'd be more in favor of bz_editfieldvalues or bz_can_edit_field_values.

Comment 9

[timeless]

Comment on attachment 273369 [details] [diff] [review]
something like this?

https://bugzilla.mozilla.org/attachment.cgi?action=diff&id=273369&collapsed=&headers=1&context=30

Comment 10

[Frédéric Buclin]

To be clear: I want a real discussion about why privs different from admin should be required to edit field values. Gerv in comment 3 and I both think it's a bad idea.

Comment 11

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 12

[Max Kanat-Alexander]

Comment on attachment 273369 [details] [diff] [review]
something like this?

All new system groups must have names that start with bz_. Ideally they should also have underscores in their names between the words.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #10)
> To be clear: I want a real discussion about why privs different from admin
> should be required to edit field values.

(I'm conflating editvalues/editfields here, because I think the same arguments apply to both. I can file a new bug if you think that they would be better tracked individually.)

On b.m.o, field and value changes are requested fairly frequently (particularly now that we're using custom fields more). It would lower the burden on admins if a wider set of people could handle those requests, and that's not really feasible if that requires admin bits (since that gives you far more privileges than would otherwise be needed).

I don't really care to argue about whether this bug should be fixed upstream or in a local customization, I only really care that it gets fixed on b.m.o. So if there's still a strong objection to taking this upstream, please let me know so that I can request the customization instead.

Comment 14

[Max Kanat-Alexander]

I'm OK with having a separate permission for field values.

Adding fields would be another bug, but that would be less likely to be accepted.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

I misunderstood the distinction between editfields/editvalues, so ignore that part of comment 13 (a separate group for just editvalues should be fine).

Comment 16

[Gervase Markham [:gerv]]

So it looks like I've entirely changed my mind from comment #3 :-) I think back then I was thinking about keeping evil people from doing bad stuff. But if you don't trust someone, why give them any admin-level privs at all? It should be more about maintaining a process around who can change what. And for that, I think adding and removing field values, particularly for custom fields, could easily be (and, on b.m.o. is) a different set of people to the global admins.

Gerv

Comment 17

[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.