353768 - "editcomponents" group is not appropriate for editvalues.cgi (Field Values)

Status: RESOLVED FIXED

(Bugzilla :: Administration, task)

Description

[bigstijn]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Bugzilla 2.22

If someone has (need for) editcomponents (eg. because he maintains a product), he has also the right to  edit Field Values (editvalues.cgi).

Changing field values has effect on the whole installation.  Sometimes, you want to give people access to the components of their product, but not to the field values.

Reproducible: Always

Comment 1

[bigstijn]

So, I would suggest to have a seperate group for "editvalues".

(and to rename the group editcomponents to editproducts )

Comment 2

[Frédéric Buclin]

I don't think we want a new group. We could use an existing one, e.g. tweakparams or admin. But I agree that editcomponents privs are not appropriate here.

Comment 3

[Max Kanat-Alexander]

Yeah, perhaps we should make it admin. That would make more sense.

Comment 4

[Frédéric Buclin]

(In reply to comment #3)
> Yeah, perhaps we should make it admin. That would make more sense.
> 

I agree. Especially now that editfields.cgi requires admin privs too. We would at least be consistent. Go for it!

Comment 5

[Frédéric Buclin]

Attachment: patch, v1

Comment 6

[Max Kanat-Alexander]

Comment on attachment 239821 [details] [diff] [review]
patch, v1

Looks good to me!

Comment 7

[Frédéric Buclin]

Checking in editvalues.cgi;
/cvsroot/mozilla/webtools/bugzilla/editvalues.cgi,v  <--  editvalues.cgi
new revision: 1.18; previous revision: 1.17
done

Comment 8

[Max Kanat-Alexander]

Added to the release notes on bug 255155.

Comment 9

[Max Kanat-Alexander]

The correct bug number for those release notes is actually bug 349423.

Comment 10

[Gervase Markham [:gerv]]

Hmm :-( On b.m.o., it would be nice to give e.g. a Thunderbird person "editvalues" so they can add new release values to the custom tracking fields, without giving them full admin access to the entire installation. So I was sad to find this bug :-(

Could we reconsider the idea of a separate group? Or how else would you solve the problem above?

Gerv

Comment 11

[Frédéric Buclin]

See bug 365767.