500 Internal Server Error (edit repository groups or user groups if owner is deleted)

Issue #64 resolved
David Pentzlin created an issue
  • 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).

Comments (10)

  1. Mads Kiilerich

    Can you provide a stack trace ... or perhaps contribute a test case for it in the existing test framework?

  2. David Pentzlin reporter
    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'
  3. riverajo

    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.
  4. Mads Kiilerich

    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.

  5. riverajo

    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.

  6. Mads Kiilerich

    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')> >]

  7. riverajo

    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.

  8. Mads Kiilerich

    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.

  9. Log in to comment