JSON-RPC-API: updating repo attributes moves repos

Issue #37 resolved
Bernhard Weitzhofer created an issue

when calling the JSON-RPC method update_repo, repositories are specified via the parameter repoid either by their numerical id or by their name. This name can be qualified by prefixed group names, separated by slashes.

Unfortunately, when doing so, the repo name seems to be interpreted first as a fully qualified repo name to identify the repo (analog to an absolute file system path), but when doing the update, it then seems to be interpreted like a relative path within the current group. This results in repositories changing their groups unintended.

Sample code to clarify:

import itertools
import json

import requests

request_counter = itertools.count()

def call(method, **kwargs):
    global request_counter
    id = 'request_%s' % request_counter.next()
    headers = {'content-type': 'application/json'}
    payload = {
        'id': id,
        'api_key': MY_API_KEY,
        'method': method,
        'args': kwargs,
    }
    response = requests.post(MY_URL, data=json.dumps(payload), headers=headers)
    data = response.json()
    assert data['id'] == id
    return data

'''
>>> # we have no repos initially ...
>>> call('get_repos')
{u'error': None, u'id': u'request_0', u'result': []}

>>> # ... and no repo groups
>>> call('get_repo_groups')
{u'error': None, u'id': u'request_1', u'result': []}

>>> # create a single repo "bar", implicitly creating group "foo" as well
>>> call('create_repo', repo_name='foo/bar', repo_type='hg', enable_downloads=False)
{u'error': None,
 u'id': u'request_2',
 u'result': {u'msg': u'Created new repository `foo/bar`',
  u'success': True,
  u'task': None}}

>>> # trying to update the repo moves the repo from foo/bar to foo/foo/bar
>>> call('update_repo', repoid='foo/bar', enable_downloads=True)
{u'error': None,
 u'id': u'request_3',
 u'result': {u'msg': u'updated repo ID:21 foo/foo/bar',
  u'repository': {u'clone_uri': None,
   u'created_on': u'2014-09-11T14:19:45.008',
   u'description': u'bar',
   u'enable_downloads': True,
   u'enable_locking': False,
   u'enable_statistics': True,
   u'fork_of': None,
   u'landing_rev': [u'rev', u'tip'],
   u'last_changeset': {u'author': u'',
    u'date': u'1970-01-01T01:00:00',
    u'message': u'',
    u'raw_id': u'0000000000000000000000000000000000000000',
    u'revision': -1,
    u'short_id': u'000000000000'},
   u'locked_by': None,
   u'locked_date': None,
   u'owner': u'admin',
   u'private': True,
   u'repo_id': 21,
   u'repo_name': u'foo/foo/bar',
   u'repo_type': u'hg'}}}

>>> # repo is now foo/foo/bar
>>> call('get_repos')
{u'error': None,
 u'id': u'request_4',
 u'result': [{u'clone_uri': None,
   u'created_on': u'2014-09-11T14:19:45.008',
   u'description': u'bar',
   u'enable_downloads': True,
   u'enable_locking': False,
   u'enable_statistics': True,
   u'fork_of': None,
   u'landing_rev': [u'rev', u'tip'],
   u'last_changeset': {u'author': u'',
    u'date': u'1970-01-01T01:00:00',
    u'message': u'',
    u'raw_id': u'0000000000000000000000000000000000000000',
    u'revision': -1,
    u'short_id': u'000000000000'},
   u'locked_by': None,
   u'locked_date': None,
   u'owner': u'admin',
   u'private': True,
   u'repo_id': 21,
   u'repo_name': u'foo/foo/bar',
   u'repo_type': u'hg'}]}
'''

Comments (13)

  1. Mads Kiilerich

    It seems like you know Python. Please see if you can contribute a fix (and test) for this issue.

  2. Udo Spallek

    IMHO, this issue is marked as resolved but not fixed.
    It is needed to apply the patch from pull request #212
    manually, at least in Version 0.3.2.
    So IMHO it is better to reopen the issue.

  3. Mads Kiilerich

    Right - that is the eternal problem with issue trackers: should issues be marked as resolved when they are resolved in the repository or when the resolution is released.

  4. Thomas De Schampheleire

    With more frequent releases, that question would not be that important. I think that for the stable branch, the trigger to release could be the resolution of issues. For example, when an issue has been fixed, there will be a release within max. 1 month delay.

  5. Udo Spallek

    I would prefer to mark them as resolved, as soon they are done and the code is pushed to the repository.

    But in this case, I can not find the code resolving the issue - even not in the default branch on tip revision:
    https://bitbucket.org/conservancy/kallithea/src/d3930bd0c14a81743c73c78e11ae703a3772512f/kallithea/model/db.py?at=default&fileviewer=file-view-default#db.py-1222

    So again: IMHO this issue is not resolved. It may be accidentally set to resolved.

  6. Udo Spallek

    Cool, thanks a lot for the pointer of the resolution, which looks even better than my
    approach on tinkering with its symptoms.
    We will try to test the patch soon.

    And I am sorry for the noise…

  7. Log in to comment