Removal if an inherited group does not remove users from said group

Bug #1085012 reported by Rolf Wojtech
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Confirmed
Medium
OpenERP's Framework R&D

Bug Description

Suppose we have a user U and groups Seller, AdvancedSeller

U is only member of AdvancedSeller.

Now we open the group "AdvancedSeller" and add "Seller" under Inherited Groups.
This works as expected, U becomes a member of Seller, so adding inheritance influences existing users.

Now we open the group AdvancedSeller again and remove "Seller" under Inherited Groups.
With the behaviour from above, I would expect that U gets removed from "Seller"´. However, he remains a seller.

In conclusion, removing inherited groups from a group does not correctly limit the group's rights.

I think I understand the technical reasons for this: Adding can be done no matter the previous state of the User, worst case is he already was in the Seller group and the additional add via inheritance doesn't hurt.

However if we want to apply removed inheritance to the user, we face the question if he is member of seller ONLY because of the group inheritance or he was added there manually before the inheritance was introduced.

I am not sure how to resolve this. Maybe group inheritance is inherently wrong and should be replaced by allowing groups to become members of groups.

I get that this is almost a feature request but I believe it is a potential security issue that adding permissions works as intended but removing permissions on the same way fails without a warning.

At the very least there should be a warning dialog after removal of an inheritance that reminds the user to manually remove the group ownership

Revision history for this message
Rolf Wojtech (rolf-wojtech) wrote :

Update:
I compared this behaviour to redmine and I believe they have a very elegant solution, at least from the user perspective.

You can try it here: http://demo.redmine.org/

Basically they seem to remember if a user was given permissions individually or as part of a group. It is impossible to manually add or remove permissions that a user was given via the group (greyed out). If a user was member of a project before his group was added, he will remain a member even if you remove his group.

I have not looked at the underlying DB yet but I wanted to point out that his is how I think it should work.

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Turkesh Patel (openERP) (turkesh-tinyerp) wrote :

Hello Rolf Wojtech,

I have checked your issue and its not bug but.
We can not remove user from child groups because in case if we have been added that user manually in child group before then also it will remove and it will break the functionality ( As u have also noted that if we have been added user in "Seller" group manually then it will also removed when we remove user from "Advance Seller").

As per your Comment no #1 : that can be possible solution for future implementation but at this time this issue is note more than suggestion.

@community: I request to take a look at this and take a appropriate decision on this.

Thanks,
Turkesh Patel

Revision history for this message
Jignesh Rathod(OpenERP) (jir-openerp) wrote :

Hello Turkesh,

Thanks for your comment.

You are correct, this type of issue might be a suggestion but it is a security issue. So we can not neglect this.

And I appreciated the detail explanation of Rolf. Additionally he also provided the temporary parallel solution as per my Opinion which would be better.
Because If someone forget to remove the assigned bug it will creates the issue and mislead to (data might be misused ;-) )

Whenever we had try to remove the inherited group it will raise the warning that reminds user have to manually remove the another group.

Hope I clear well.

Thank you!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.