1885: Permissions to restrict viewing of all commits and closing review requests
- Fixed
- Review Board
| dmitry.mu*********@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| March 31, 2011 |
http://reviews.reviewboard.org/ What version are you running? 1.5 What's the URL of the page this enhancement relates to, if any? Describe the enhancement and the motivation for it. We are using review board for a post-commit reviews. Commit hook in svn ensures that all commits get listed in review board and must be reviewed. Unfortunately it seems that there is no way to prevent commit author from closing his own review request. So developer can discard review request and there will be a chance for his code to skip review. Another problem is that there are some outsource teams working on our project. We want to review their code (same scheme - review goes after commit), but we do not want them to view all commits in the system. For example we want to restrict them from viewing commits to our security subsystem. Third problem is that user can add himself to any review group. It would be nice to have more granular control over permissions in the listed cases. Perhaps role system and developer/reviewer roles can help here and only allow developers to view reviews for their own code, also reviewers can be restricted from viewing code they are not responsible for (only default reviewer gets access). Though these are features not needed for an open source projects and pre-commit-review schemes, their absence makes Atlassian Crucible the only suitable code review tool for companies with more strict security and workflow requirements. What operating system are you using? What browser? Please provide any additional information below.
I would appreciate that feature too. At our institute there are projects whose code is restricted to a small group of people working on that project. Pushing all code as post-commit review to review-board would enable everyone to see that code. I would add to the request above a request to restrict permissions regarding specific repositories. Otherwise one would be able to see code you have no svn-access to by simply expanding the diff in the diff-view. From that, more paranoid, point of view I would also appreciate to let every user provide his own repository credentials instead of having one fixed account communicating with the repository.
The in-development 1.6 has invite-only groups, allowing you to limit who can be in the group. It also has the ability to restrict access to a repository, to one or more invite-only groups or to specific users. There is nothing for limiting who can close out a review request. I'm not sure that's something we'll be doing for 1.6, but we'll consider it. Most likely, that will wait, though, as everyone's going to have different rules for how that should work (we've already seen many very different, incompatible requests). Both the original request and the reply list many feature requests. Please file one bug report per request so that we can close them out when the particular feature is implemented.
These are all possible now with 1.6 - Invite-only groups can handle the cases where you want to limit who's in a group, and who sees a review request - Repositories have group and user-level access lists - You can keep developers from closing reviews for their own code by using --submit-as to post their code under a different username.
-
+ Fixed