Issue #139: Repo Group assigned top-level parent by mistake
Reported by: | Bosco Rama |
State: | new |
Created on: | 2015-06-03 07:47 |
Updated on: | 2015-07-27 20:15 |
Description
When a user has Admin rights to a single Repo Group, and that Repo Group resides in another Repo Group, the target Repo Group will be assigned the 'Top Level' (aka root) as the parent Repo Group whenever the user hits 'Save' in the Settings tab for the repo group.
Since the user has no options available to choose as the parent (not even the current parent since they do not have admin access to it) the Save will determine that the caller has asked for the Top Level and assign it even though they are not allowed to use the Top Level as a parent (that is, 'can_create_in_root=false' is being ignored).
Kallithea version: Current stable from repo
How to reproduce:
- Create a Repo Group (e.g. Group1)
- Create a sub-group of that group (e.g. SubGroup1)
- Assign a user as Admin of SubGroup1 that does not have Admin rights to any other Repo Groups
- Login as that user and edit the Repo Group settings for SubGroup1
- In the Settings tab hit Save. (Note that there are no options for 'Group Parent')
The SubGroup1 Repo Group should now be parented at the Top Level instead of Group1. What's more, the user cannot reassign it back because they don't have Admin rights to Group1.
Attachments
Comments
Comment by Mads Kiilerich, on 2015-07-15 19:14
@patrickdepinguin I will fix this if you make a test ;-)
Comment by Thomas De Schampheleire, on 2015-07-15 19:20
@kiilerix Deal
Comment by Thomas De Schampheleire, on 2015-07-27 20:05
@kiilerix Do we have a deadlock here? I was waiting for you to make a fix before making a test, but maybe you were waiting on the test? :-o
Comment by Mads Kiilerich, on 2015-07-27 20:15
More like a live-lock. I might have solved it with my recent refactorings. The test will show it.
But some people like TDD so ideally we should start with a "failing" test and then make it pass ;-)