Reviewers are not automatically added to Collaborator review based on BitBucket pull request
Hello. When we create a pull request in BitBucket, a Collaborabor review is automatically created, and the pull request creator is correctly assigned the role of the review's author. Question: We also specify some BitBucket users as reviewers when creating the pull request, but those users are not automatically added as reviewers to the Collaborator review. Has anyone gotten this to work? The Collaborator document indicates that this automation should work: https://support.smartbear.com/collaborator/docs/ver-13-9/source-control/repo-hosting/bitbucket-server.html "You can specify Bitbucket users as reviewers when you are creating a pull request. If your teammateslinktheir Bitbucket accounts with their Collaborator accounts correctly, then Collaborator will automatically add those users as reviewers to the created review on the Collaborator side." Thank you!
Extend the list of roles available for review participants
Hi, 1. Currently, as review participants, Collaborator providesonly the moderator, author, reviewer and observerroles. Can this list be extended ? https://support.smartbear.com/collaborator/docs/server/settings/review-templates/roles.html 2.In addition, is it possible to assign more than one role to one person?
How to Allow Multiple Groups Access to Reviews w/o Nesting
How can Review access be granted to more than one group without having to nest those groups as children of a parent group? Example: An organization has 3 project teams, but we would like to only grant access to 2 of those 3 teams. Any combination of 2 teams could be required for a review. We would like to be able to allow access to multiple groups without having to create parent groups for every combination of team collaboration... especially as the number of team combinations increases.
username discrepancy between ldap, sso and git result in "not participating" error
Hello, We have collaborator13.6.13601 enterprise, and recently a few users that have a specific prefix in their username in ldap, are not assigned a role on a review, instead they get "not participating", see screenshot. in ldap the user is `t_foo`, where "t_" denotes a contractor/temporary employee If we go into the user admin section and rename the user to "t-foo" to match what Github uses, the old "t_foo" user is recreated in Collaborator automatically, and the user still cannot be assigned to a review properly. Most of our users have the username convention "<lastname><f>"Assign Review Pool JSON API
Hello, I'm trying to use the JSON API to assign a review pool to a role in a review here is my call: {"command": "ReviewService.assignReviewPool", "args" : { "reviewId" : "123" "assignment" : { "poolGuid" : "123456abcdef" "role" : "REVIEWER" } }} And this is the response it returns: {"errors": [{"code": "ReviewPoolNotFound", "message": "No review pool assignments with Group guid "123456abcdef" and Role REVIEWER were found in Review 123, or the given user does not have the right group membership to get that assignment"}]} I've double checked the group guid and the role, both seem to be correct. I'm also pretty sure I should have the correct permissions to execute this, I am able to assign the group to the role from within the GUI Is there something wrong with how I am making this call? Thanks!
Review Pool Subscriptions duplicate additions (unusable)
As of Collaborator 11.1, the file subscription mechanism for review pools has a bug that makes it unusable by adding many duplicate Review Pool slots to reviews. We have three types of file filters that need to require a single member from a specific review pool to review the changes. What we get is an entry for the review pool in the participant list for every file matching each of the filters. So for example, our review pool is intended to watch Makefiles. We have review pool file filters for: **.mk building/* Makefile If a user adds: Makefile, building/somefile.mk building/someotherfile.mk We end up with 5 review pool participants. One for each of the files matching the first filter, one for each of the files matching the second filter (even though the same files were already matched by the first filter), and one for the third filter. The issue seems to be in the implementation of the participant file filter is implemented. With most users it blocks subsequent adds because you can only have a review on the review in one role. Theoretically it does some comparison to promote the participant role when duplicate roles are requested (I've never tested it). With Review Pools, it's possible to add the same pool multiple times, so the logic that blocks duplicate additions to the same review doesn't apply/work.
