355870 - Users with editcomponents privs can create products they can't edit if makeproductgroups and useentrygroupdefault are on, and they aren't admins

Status: RESOLVED WONTFIX

(Bugzilla :: Administration, task)

Description

[stijn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1) Gecko/20060918 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1) Gecko/20060918 Firefox/2.0

when a creategroups user (not admin) creates a new product, and the makeproductgroups flag is on, the product is not available for this user.

bug located in editproducts.cgi line 250 (bugzilla v2.22)

        # If we created a new group, give the "admin" group priviledges
        # initially.
        my $admin = GroupNameToId('admin');

I suggest to change this so initially the "creategroups" group has privileges to this product. rules can be sharpened later on if needed.

code change:
        # If we created a new group, give the "creategroups" group priviledges
        # initially.
        my $admin = GroupNameToId('creategroups');




Reproducible: Always

Steps to Reproduce:
1. have a user with creategroups rights
2. have the makeproductgroups flag on
3. create new product
4. product not available for this user

Actual Results:  
product not available for this user

Expected Results:  
user needs to see this product and do his thing with it.

Comment 1

[Frédéric Buclin]

You cannot create new products with creategroups privs. You need editcomponents privs. But even by replacing 'creategroups' with 'editcomponents' in your comment, this is something we are not going to fix.

I see 3 possible fix related to this problem:

1) WONTFIX. Users with editcomponents privs can only edit products they can see. That's on purpose (we even fixed a bug about that).

2) only let administrators create new products if makeproductgroups is on.

3) automatically add this user in the group generated by this product, but only if this group doesn't exist yet (else I could create a product named 'admin' and I would automatically be added to the 'admin' group!).


All 3 suggestions are fine for me. Max, Dave, what do you think?

Comment 2

[Max Kanat-Alexander]

WONTFIX. This is the intended behavior--if you aren't in the group, you can't see the product.

If you had editusers, you could add yourself to the group.

Comment 3

[Frédéric Buclin]

Well, I'm not sure that allowing users to create products they cannot edit is desired nor per design. In this case, I would prefer to implement my solution #2.

Comment 4

[Max Kanat-Alexander]

Okay. If makeproductgroups is on, then people should have to be in editusers in order to make a product. The error message should explain why, though.

Comment 5

[Max Kanat-Alexander]

Okay, I think you have to also have to have "useentrygroupdefault" turned on.

Because "makeproductgroups" only creates a Default group--it doesn't create a Mandatory group!

Comment 6

[Frédéric Buclin]

OK, I will have a look at this bug when 2.23.3 will be released. I haven't time this week.

Comment 7

[stijn]

(In reply to comment #4)
> Okay. If makeproductgroups is on, then people should have to be in editusers in
> order to make a product. The error message should explain why, though.
> 

Meaning I only need to give these users the editusers rights to solve this issue?

That solves it for me also.

Comment 8

[Frédéric Buclin]

(In reply to comment #7)
> Meaning I only need to give these users the editusers rights to solve this
> issue?

No way! Having editusers privs is much more powerful than having admin privs! That's not something you want to give to users so easily as this means giving them full power on your installation.

I don't like Max's suggestion as editusers privs has nothing to do with products. So either request 'admin' privs (my suggestion #2) or we implement my suggestion #3. But I definitely want to separate editusers privs from product/component stuff.

Comment 10

[Frédéric Buclin]

I can reproduce the bug. We will have to fix it at some point.

Comment 11

[jessn]

What are the target milestone for this particular bug? 

I have observed it in vers. 2.23.3+ as well. 
Does the bug also exists in vers. 3.0?

Comment 12

[Marc Schumann [:Wurblzap]]

The useentrygroupdefault parameter's days are counted. See bug 478972.

Comment 13

[Max Kanat-Alexander]

LpSolit: Is this WONTFIX now that we've removed useentrygroupdefault on HEAD?

Comment 14

[Frédéric Buclin]

(In reply to comment #13)
> LpSolit: Is this WONTFIX now that we've removed useentrygroupdefault on HEAD?

Yeah, this is no longer an issue in Bugzilla 3.5. And we won't fix it in 3.4.