Git Repository Name on review with multiple git repository.
When you add several changes from git via GUI client to one review there is no way to understand which repository the file belongs to. For example(screen in attache), if several commits contain files with the same name, you can only understand which repository they refer to using a hash. The screenshot shows an example when all 3 files with the same name refer to different repositories. Adding the name of the repository, and not just the file with changes, would help us a lot. Thanks for attention!
Previously Accepted Comment
Since comment acceptance clears on file upload, it would be helpful to know which comments were previously accepted. So you would have 3 icons, unaccepted, previously accepted and accepted. This way it makes accepting a comment useful and not just cleared on a new upload. This way if you didn't change anything related to that comment you know you don't have to go back and look at it or get someone to reaccept.
Add multiple pull requests to "Remote System Links"
Currently a pull request from Bitbucket can only be added to the Remote System Links section automatically when the pull request is created, and there isn't a way to add a link to a pull request manually. Is it possible to make an update that allows linking of more than one pull request in a single review? In the case of making small related changes across multiple repositories, it would be very beneficial to be able to include more than one pull request in a single review, to allow those changes to be reviewed as a set.
include assignee from defects in action report or at least on reports
We utilize the assignee field on defects to drive action items. However, we have not been able to find a way that this is communicated in any method outside of the actual review. Having this on the home page and/or notification activity (tray, in app, email) would help to expedite action.
Reviews of a submodule change need to show file change in review
When using a git submodule with a pull request / merge request mechanism enforced (i.e., Bitbucket), when the developer changes the submodule and there is no other change in the parent repository other than pointing to the new merge commit, Collaborator shows no files in the review. Commits are properly listed, but there are no changes to actually review, which is incorrect. Bitbucket, for example, lists the "pointer file" that holds the submodule commit reference. It would be extremely helpful to have Collaborator show this difference as well.Add a "Ready for Approval" state to defects
It would be helpful if there was a third state to indicate that a defect has been resolved, but still needs to be "approved" (marked Fixed) by the author of the defect.Currently a defect only appears as "Open" or "Fixed" in the Defect Log. It is difficult to tell which defects have been resolved without looking through the comments, or having someone tell you to look at a specific defect. When there are a lot of defects in the Defect Log, a third state to filter on would make it easy to identify those defects that need to be marked Fixed. Maybe this could also be shown with a different color bug, instead of red or green.Review Materials section make it easy to identify the logged in user in the list of participants
In a large review with many files and multiple participants, if you are not the first or last participant, it is hard to know which column is yours in the list. This makes it difficult to see if you have already accepted a review which causes unnecessary scrolling. A few possible solutions: Always make the logged in participant the first column of the list of participants. May not work well when someone how isn't an participant of the review is looking at the review, but this is rare and they probably aren't looking to see what files they haven't reviewed. Draw the left and right column lines with a heavier weight. For example:
