post-review permission denied searching for repository

[heffe]

I have an issue where it appears that Review Board's ability to configure a repository as invitation only is getting in the way of post-review.  A user is submitting a review request using post-review, and from the debug output I can see that the tool is iterating over the configured repositories looking for one that matches the sandbox URL where post-review is running.  The last repository it shows is one that I think is configured as invitation-only, and the user running post-review does not have access to this repository.  I'm assuming this is the case because the post-review output suggests that repository "5" is the one with the permission problem, and when I go to edit my repositories, the URL for the repository that ends in "5" is the one that is invitation-only.  Below are the details:

$ post-review --debug BigWidget.pm --user=jimmy
>>> RBTools 0.4.1
>>> Home = /Users/jimmy
>>> HTTP GETting api/
==> HTTP Authentication Required
Enter authorization information for "Web API" at rbserver.mydomain.com
Password:
>>> HTTP GETting http://rbserver.mydomain.com/api/info/
>>> Using the new web API
>>> HTTP GETting http://rbserver.mydomain.com/api/repositories/
>>> HTTP GETting http://rbserver.mydomain.com/api/repositories/9/
>>> HTTP GETting http://rbserver.mydomain.com/api/repositories/9/info/
>>> HTTP GETting http://rbserver.mydomain.com/api/repositories/5/
>>> Got API Error 101 (HTTP code 403): You don't have permission for this
>>> Error data: {u'stat': u'fail', u'err': {u'msg': u"You don't have permission for this", u'code': 101}}
Error creating review request: You don't have permission for this



When I look at the admin site for Review Board, the repository that is invitation-only is:
    http://rbserver.mydomain.com/admin/db/scmtools/repository/5/

Is there a problem where the Review Board API does not allow post-review to pull the information it needs to proceed when it runs across an invitation-only repository?  We are running RB server 1.6.3 and have had this problem when using post-review 0.3.4 and 0.4.1.

Thanks,
Jeff

[Christian Hammond]

Hi Jeff,

To my knowledge, so long as "jimmy" is in that repository's access list, it should be working. We have unit tests that cover this, so it's surprising to see it (and we've used it ourselves and it works).

What happens if you access http://rbserver.mydomain.com/api/repositories/5/ in your browser?

Christian
 
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com

--
Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to reviewboard...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en

[heffe]

That's the problem.  "jimmy" is not authorized to access the repository where post-review is running into the error.  The review being created by post-review is not against the repository that is invitation-only.  It is against another repository in the list that post-review hasn't gotten to yet.  The question is, if post-review iterates through the repository list on behalf of user "jimmy", but runs across a repository where it can't get the data because of permissions, and hasn't yet reached the one that is appropriate for the sandbox, does it just fail as I am seeing?

Example list of repos that post-review iterates over to find out where to submit the request:
[repo1] - public
[repo2] - public
[repo3] - invitation-only
[repo4] - public, the one where "jimmy" intends to submit the review request.

Thanks,
Jeff

[Christian Hammond]

Ohh, interesting. Yeah, definitely a bug there.

What type of repository is this?

Christian

--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com

Thanks,
Jeff

--

[heffe]

All repos in this situation are SVN.

Thanks,
Jeff