Reference the Line of Another File in the Same Review
In the chat box of file foo.cc I would like to reference a specific line in file bar.cc.For example, I have bar.cc:line 12 written in my code collab chat box. In this case, code-collab only recognizes and allows the jump to bar.cc, but not to the line. I would like a featurewhere a designer canwrite a reference to line 12 in bar.cc and Collaborator automatically auto-links the to the correct line.
Renamed/moved file shown in Review Materials
Indicate either in the Review Materials overview, or in the file differences view when a file has been moved or renamed. This information is tracked by a number of Version Control systems, and clearly indicated when examining the differences between commits/check-ins. Currently a moved or renamed file will show up as completely removed from the old location (all contents removed) and completely added to the new location (all contents added). If changes were also made within the file in the same range of commits/check-ins under review, they can't be differentiated. As a possible implementation, both the old and new file names in the Review Materials overview could link to the same file differences view where the before and after file names are listed as different at the top of the window (where there's currently only one center-aligned file name as of 11.0.11000).Manually specified file version selector names when uploaded from client via Git
Problem: I upload changes as a commit range in git between a reference branch (master) and my current HEAD. I then later need to rebase my current HEAD against an updated reference branch (master) and re-upload the changes. It cannot be differentiated in the file version selector during a review which versions of the file are reference branch (master) and which are HEAD versions. Generically, client tool uploaded differences from git commit ranges automatically label all versions of files as seen in file version selector drop down, with check-in time and non-human readable git object hash (not commit hash) only. Rebasing changes against the latest version of the reference branch, or merging the latest version of the reference branch into the changes, between a first and second upload to a review causes the "before" version from the reference branch to be different during the second uploaded of files and have a newer timestamp than the "after" version of the file from the first upload. The "before" versions therefore can't be differentiated from the "after" versions in the drop down. Solution: Add optional command line argument for "addgitdiffs" that will allow user specified names to be added to the before and after versions of all files included in the commit range. Conflicting names are automatically appended with standard "(1)", "(2)", etc for a given file based on upload order. For example, if I have changes on a "work" branch that originally forked from "master" branch and changed fileA and fileB, my upload command would be ccollab addgitdiffs --before-name="master" --after-name="work" ask master...work which would upload all changes made on the work branch since it split from master by uploading fileA and fileB from the commit on the master branch right before the work branch split, and fileA and fileB from the head of the work branch (currently). The extra arguments would add labeling for all the files from master as "master" and those coming from the work branch as "work" (new). When my review continues for a while and I need to rebase my work branch against the since-updated master branch I'll need to re-upload my changes relative to the new reference point on the master branch. Running the same command as before accomplishes that but causes a problem. When the differences in fileA are viewed without this feature, what's seen in the file version selector drop down is (larger numbers with the timestamps indicate newer timestamps): "<git object hash> <commit timestamp 1>" <---- from master branch in first upload "<git object hash> <commit timestamp 2>" <---- from work branch in first upload "<git object hash> <commit timestamp 3>" <---- from master branch in second upload "<git object hash> <commit timestamp 4>" <---- from work branch in second upload With the recommended feature this list becomes much more clear: "master <git object hash> <commit timestamp 1>" <---- from master branch in first upload "work <git object hash> <commit timestamp 2>" <---- from work branch in first upload "master(1) <git object hash> <commit timestamp 3>" <---- from master branch in second upload "work(1) <git object hash> <commit timestamp 4>" <---- from work branch in second uploadFile permissions changes included in file reviews
File permissions can be a critical factor in files, and many Version Control systems allow creation of commits/check-ins that consist solely of file permissions changes. Request: Add the file permissions to the file differences view so they can be seen. One possible implementation might be to show the permissions settings next to the file name in the file difference view for the before and after files selected, and highlight differences.
Mention and Notify User From Review Comment
I would like a way to indicate to another Code Collaborator user that a comment I've made requires their input and notify them specifically about that action item. In several tools including Jira, Azure DevOps, GitHub, GitLab, and others (including this form, apparently), you can type "@[user name]" where "[user name]" is the name or nickname of another user and that user will be directly notified that they have been mentioned in a comment. The use case I have for this is to expedite communication in conversational comment threads. Sometimes I may have an idea for a change or issue in a review, but I want feedback from another user with relevant experience, so I would mention them to indicate I'd like their input. Currently, I can poke the user, but then they don't have any context for why they've been notified. Ideally, a mention system would search based on display names since our SSO setup requires login names that look like random text. An autofill system would make using this feature much easier. Additionally, having some marker on the website that indicates where you've been mentioned would be useful.
Allow Admins to close reviews
Bringing back an old thread - I'd like anyone with Admin privileges to be able to move a review to Completed. We've had several instances where someone has left the company, or is on extended leave, and their roles is required to move a review to completed. On solution is to shuffle roles - while that will allow a review to close, it's "not right". If the author of a document is out sick - yes I can assign the author role to someone else - but now you are fudging the review records in order to get the closure. Later when an auditor comes in we have to give a song and dance as to why the roles in the review don't represent the actual roles the staff members have. We shouldn't need to alter the records to move things forward. The review is more than a record of defects - it's a record of who did what, and we shouldn't need to compromise that to get around a technical glitch.
Review sent to rework displayed as requiring attention
As a reviewer, if I send a review to rework, it then is displayed with the status "Waiting for defect rework" with a yellow arrow. However, if the author then comes back with some comments, even if I mark them as read, the review is now displayedwith the status "Rework defects" and is displayed with a red arrow indicating that it requires my attention. Previously there was an option to put it back into the waiting state, but now there is no option. The review sits in my list as if it needs my attention. When the rework is actually done and there are new files uploaded it won't be obvious."Confirm to cancel comment" dialog wording is awkward and unclear.
If I write a comment on a review and later want to delete it, I click the Delete button to do so. The message which then appears looks like the image below: So I have to click Confirm if I want to cancel, and Cancel if I want to cancel the cancellation; i.e. I don't want to cancel the comment. I think. I think it would be a lot clearer if it used the word "Delete" instead of "Cancel", so could say "Are you sure you want to delete this comment?", and had Yes/No buttons, such that Yes deletes the comment, and No doesn't.
