Kallithea issues archive

Issue #64: 500 Internal Server Error (edit repository groups or user groups if owner is deleted)

Reported by: David Pentzlin
State: resolved
Created on: 2014-12-18 09:22
Updated on: 2015-01-20 22:04

Description

Had this problem with rhodecode 2.2.5 as well. (you cant edit the owner of these groups btw).

Attachments

Comments

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.

  1. 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 delete just 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.
  2. 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.