Collaborator Feature Requests

Would like Collaborator to be able to interface with the Sharepoint ecosystem in a similar way to how it interfaces with other repositories. ... View more

Currently once you have typed a comment you have to use the mouse to click Add.   Ctrl+Enter should add the comment like in many other applications. ... View more

I would like to see support for reviewing local HTML documents, where I can navigate, drop pins and see differences from within the Collaborator environment. Something related has already been done with the Simulink review tool. ... View more

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. ... View more

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 feature where a designer can write a reference to line 12 in bar.cc and Collaborator automatically auto-links the to the correct line.   ... View more

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.    ... View more

Rather than having to click on each file to exclude it would be good if we could exclude content by folder, by file filter, by holding down the shift key and selecting 15 files at once. Things that allow working with and excluding large lists of files easier and less time consuming to ensure just the essential files are included in any review. Not much thought or effort has been put into the current mechanism. ... View more

The list of current reviews (or "Action items") only allows just less than 8 items to be visible, no matter what the size of my browser window causing me to scroll if there are a larger number of reviews open.   Could we have a splitter bar that could be moved down to make that list view larger and have more items visible without scrolling? ... View more

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! ... View more

We use the "Message from the administrator" feature to show important information to users about the type of data they can use Collaborator for, however in v11.3.11301 the message is always present at the top of the screen.  There is no way for a user to hide the message and it consumes valuable screen real-estate.  Many of our users review portrait format documents on landscape screens and so being able to hide or move anything that prevents the use of the full vertical size of the monitor would be beneficial.   Please provide an option for users to be able to read, accept and hide the message upon each login.  Better still, provide an option to do that and also to hide/move/shrink the horizontal menu bars.   Thanks! ... View more

Would like the ability to identify and restrict access to Reviews containing Export/ITAR restricted data.   Recommend having the option to identify a Group as ITAR restricted or non-ITAR, which would then activate a corresponding field for each user in the group. User accounts should also allow this property to be selected independently from the group. An "Export Restriction" field would get added to Reviews and when that field has "ITAR" selected, it prevents any users with the non-ITAR property on their account from accessing the review. ... View more

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. ... View more

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 displayed with 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. ... View more

Users are complaining about this setting: Allow Reopening Completed Reviews Once a review has completed, should participants be allowed to re-open the review just by making an additional comment? If not allowed, an administrator is still able to re-open a review by clicking a link.   They want to be able to comment on a Closed review without Re-opening it, but also be able to Re-open reviews without an Administrator. One way would be to make the re-open link mentioned above available to all - maybe add a separate setting to enable that... ... View more

In a Large enterprise there will be multiple admins. To track who has done what, Admin should be able to get the log of all users activities. Like, Disabling and Enabling review templates, Disabling and enabling users or adding users etc. In simple terms a log should be generated for every activity happens in Collaborator through all the ways. ex: GUI, API, Collab client, Thirdpart clients, Commands etc.   ... View more

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 upload     ... View more

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). ... View more

It would be great to be able to designate observers in addition to reviewers to co-sign the document without changing their status to reviewer. ... View more

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. ... View more