Issue #64: 500 Internal Server Error (edit repository groups or user groups if owner is deleted)
|Reported by:||David Pentzlin|
|Created on:||2014-12-18 09:22|
|Updated on:||2015-01-20 22:04|
- Add user
- make user admin
- create with this user groups (repo or user group)
- delete user
- you get an internal error if you try to edit groups
Had this problem with rhodecode 2.2.5 as well. (you cant edit the owner of these groups btw).
Comment by David Pentzlin, on 2014-12-18 09:23
Comment by Mads Kiilerich, on 2014-12-18 14:35
Can you provide a stack trace ... or perhaps contribute a test case for it in the existing test framework?
Comment by David Pentzlin, on 2014-12-18 17:10
oGroupsController:__before__ Error - <type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'username' URL: http://localhost:5000/_admin/repo_groups File '/opt/kallithea-venv/local/lib/python2.7/site-packages/WebError-0.10.3-py2.7.egg/weberror/errormiddleware.py', line 162 in __call__ app_iter = self.application(environ, sr_checker) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Beaker-1.6.4-py2.7.egg/beaker/middleware.py', line 155 in __call__ return self.wrap_app(environ, session_start_response) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Routes-1.13-py2.7.egg/routes/middleware.py', line 131 in __call__ response = self.app(environ, start_response) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Pylons-1.0-py2.7.egg/pylons/wsgiapp.py', line 107 in __call__ response = self.dispatch(controller, environ, start_response) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Pylons-1.0-py2.7.egg/pylons/wsgiapp.py', line 312 in dispatch return controller(environ, start_response) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Kallithea-0.1-py2.7.egg/kallithea/lib/base.py', line 383 in __call__ return WSGIController.__call__(self, environ, start_response) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Pylons-1.0-py2.7.egg/pylons/controllers/core.py', line 211 in __call__ response = self._dispatch_call() File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Pylons-1.0-py2.7.egg/pylons/controllers/core.py', line 162 in _dispatch_call response = self._inspect_call(func) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Pylons-1.0-py2.7.egg/pylons/controllers/core.py', line 105 in _inspect_call result = self._perform_call(func, args) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Pylons-1.0-py2.7.egg/pylons/controllers/core.py', line 57 in _perform_call return func(**args) File '/opt/kallithea-venv/local/lib/python2.7/site-packages/Kallithea-0.1-py2.7.egg/kallithea/controllers/admin/repo_groups.py', line 149 in index "owner": h.person(repo_gr.user.username), AttributeError: 'NoneType' object has no attribute 'username'
Comment by riverajo, on 2014-12-22 17:57
I was looking into this on rhodecode, before all the changes. It's trying look up a username that no longer exsists to put it in the page. I think there are 2 ways to fix it.
- Catch it before deleting a user and leaving "orphaned" groups. would have to go into the user model and have it throw an exception on
deletejust like if you try and delete a user and it still owns repositories. This way is more consistent, but would require more code, it also makes it pain to delete users because you have to change ownership of all groups before you can delete.
- Allow orphaned groups and just say it's owner is default or something if it has no owner. This one is easier I think, just check if
repo_gr.user is None.
Comment by Mads Kiilerich, on 2014-12-22 18:29
IMO, users should not be deleted if they still are referenced in the system.
I will fix the issue (or review a fix) if someone else can contribute a test case for it in the existing test framework.
Comment by riverajo, on 2014-12-22 21:56
Ok, submited pull request 64 that has tests for denying a user delete if it still owns groups. I imagine the cleanest way to do this is add a
RepoGroup relationship on the
User class, then just bubble up an exception when the relationship is not empty just like repo the one. Let me know if I'm way off base.
Comment by Mads Kiilerich, on 2015-01-06 00:00
Fixes has been pushed.
Comment by Mads Kiilerich, on 2015-01-20 17:34
Somewhat related: I noticed that trying to delete a user group which still has access grants will fail with an odly looking error:
RepoGroup assigned to [<UserGroupRepoToPerm:<UserGroup('id:14:yada')> => <Repository('30:yum')> >]
Comment by riverajo, on 2015-01-20 21:54
I'm not sure what you mean by "access grants", also is that a stacktrace from the logs or what shows up in a flash message? I might be able to put together a test if you can clarify.
Comment by Mads Kiilerich, on 2015-01-20 22:04
The group I was trying to delete had been granted access to a repo. It could have been handled with recursive delete ... but I would prefer just to get a cleaner error message that also was consistent with the messages we discussed here.
If you feel like it, please try to fix the "issue". I am not sure - we might already have test coverage for this. This is more of a "unpleasant user experience" than a "real bug" that we can test.