Collaborator Feature Requests

Howdy,   Please add Code Collaborator support for AWS Code Commit repository integrations to the web client.   Example of this current functionality can be found here: https://support.smartbear.com/collaborator/docs/source-control/git.html https://support.smartbear.com/collaborator/docs/source-control/repo-hosting/index.html   In the same way that Github, Bitbucket, and Azure can easily be integrated to the Collaborator, I would like for this process to also function with AWS Code Commit Repos. I may currently use Code Collab and AWS Code Commit via the client gui and local changes, but I would also like to have direct repo integration like the hosted repos do.   Thanks. ... View more

Submitting a feature request on behalf of Symantec Corp: There is no possibility to add a Perforce SCM repository in Collaborator Visual Studio plugin at this moment. The idea is to add Perforce SCM support to Collaborator Visual Studio plugin to make it possible. ... 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

When integrating with GitHub and GitLab, a separate Remote System Integration must be added for each project/repository.  However GitHub and GitLab operate with a single account list per installation instance, and then a member filter per project/repository.  This results in users needing to repeat identical username information for every repository/project the Collaborator instance is integrated with.   Instead, the Remote Repository Integration could separate systems from repositories/projects.  A "System" would be a configurable list that would present to the Users as needing their username to match.  Repositories/Projects would look like what is currently provided, for Remote Repository Integration, but would have a mandatory "System" drop down to select which of the configured  "System"s the repository is associated with.  If a specific repository needs slightly different settings from the rest of the repositories in it's existing "System", a new "System" could be added with those variations and selected as the associated "System" for that one repository's configuration.   In most cases, a number of repositories are hosted in the same GitHub or GitLab instance.  When Collaborator is used as the primary review tool, it's likely many or all of the repositories will be integrated with Collaborator under only a few different credential settings (depending on how many different GitLab and/or GitHub instances exist).    In our current use case, we have almost 40 repositories hosted on only two GitLab instances.  That means when we complete our integration, each user will have to enter one of only two different usernames almost 40 times. Even though we have Single Sign On via Active Directory being used for Collaborator and both GitLab instances, GitLab has decided usernames are the human readable version of a user's name as listed in their profile, so no automatic matching can easily occur (all GitLab's fault). ... 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

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

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

This is what we run into if a user has 3 or more Collaborator configurations... When our users change their network password, once they open the Collaborator client (which has their old network password in their ClearCase configurations), it immediately locks their network account which then throws a validation error in Collaborator.   It would be better if you didn't have Collaborator auto validating upon open so that users have the chance to either remove these configurations, or edit them to change the password.   Also, I think it would be better to have a single place for the user credentials instead of in each configuration. That way the user would only have to change it in one place.  ... View more

Is there a way for Collaborator to look at the history of a file when an SVN add occurs? Right now, with TortoiseSVN, most of the time an SVN mv is done as an SVN rm and SVN add. As a result, when we set up a review that contains a file that this has been done to, Collaborator shows the file as being deleted and then as a completely new file, so that we cannot see the changes that actually occurred in the source code. ... View more

Since Collaborator uses the Subversion command-line client and its native commands to fetch the data from the local SVN repository or the SVN server, Collaborator will abort the entire uploading process if at least one of the outputs of the native commands will be unexpected or contain an error. This is done to prevent losing data or uploading the incorrect files to the Collaborator server.   It would be good if CodeCollaborator would be able to handle importing a review from which a file has been removed during a merge to handle this differently. i.e: continue to import the files it could parse, and maybe put up a warning or something, rather than aborting the import. ... View more

In the Collaborator Enterprise Client GUI, click “Add Subversion Diffs”. Click the “Revisions” tab. Change the Subversion URL to be the top level of the directory structure you want to diff. The “Before Revision” should be the last SVN commit that was reviewed (see SVN’s “Show Log” for the revision ID).   However, at this point, you cannot chose to include/exclude some files from some of the revisions. This is useful when certain things should be submitted to the repository but not reviewed (*.bin files for instance). This would be a nice feature. ... View more

      Allow the review creator and reviewer(configurable) to make changes in the GUI like Win Merge, saving the changes to the uploaded change list. Allowing the reviewer to make changes would be great for training a junior developer, The reviewer could fix certain issues while commenting on what they did any why. It would save time having to manage the code in a separate editor, it would also save time in having to deal with some repository software (ie: Tortoise SVN).   ... View more

The addgitdiffs command uses Git commit hash syntax identical to the git tool itself except in one regard: specifying individual commit hashes for addgitdiffs is handled the opposite of how the git tool does it.   In Git syntax the following lines are identical: git diff AAAAAAA..BBBBBBB git diff AAAAAAA  BBBBBBB   In the Collaborator command-line client the following lines have exactly opposite meanings: ccollab addgitdiffs ask AAAAAAA..BBBBBBB ccollab addgitdiffs ask AAAAAAA  BBBBBBB   This seems to be because the addgitdiffs command handles the second case as a list of individual commits, which it assumes are in reverse chronological order (newest to oldest), rather than a direct pass-thru to the git tool (oldest-first) like the first command.  To resolve this, split the addgitdiffs command for specifying a list of commits into a separate command (or require extra options). ... View more