One fine summer day, "Jane Smith" (sAMAccountName/username == "janesmit") gets married, and changes her name to Jane Johnson. After returning from her honeymoon and going back to work, she logs into her computer and other applications as "janejohn", and all is well.
Unfortunately, when she logs into her company's instance of Collaborator (which uses LDAP Auth) as "janejohn", it is as if she has an entirely new account - the old account "janesmit" is separate, and she no longer has access to the reviews associated with her old account ("janesmit"). Collaborator does not act appropriately when accounts are renamed.
Jane is understandably not happy, and writes an email to the maintainers of Collaborator at her company, asking for the accounts to be merged. Unfortunately, Collaborator provides no such capability to the administrators of the tool, and Jane is sad. If only SmartBear would add the ability for an administrator to merge accounts, Jane would be happy.
When a user attempts to upload a file that is in the "restricted file types" list (a .SH file for example), Collaborator does not indicate to the user that the file was blocked, causing confusion.
The Collaborator server should indicate to the user that some of the files were blocked because they are on the restricted file list.
The Collaborator Enterprise Client's "Add Git Diffs to Review" modal window allows to specify Diffs to review by selecting the Before branch and After branch. We can browse thru existing branches thanks to the drop-down lists (see attached snapshot), but this can quickly become inconvenient when the number of branches increases. There are also some really irritating cases :
Solution > Persist the latest selected branches for a given existing review and user and allow to have the branches pre-filled
Solution > Configure a default 'Before' branch so that it can automatically be picked up for new reviews.
Our Dev team can create some reviews containing a lot of various files (eg. *.cs, *.xml, *.csproj, *.config...).
When reviewing the files under the 'Review Materials' section, we would like to filter the files by their extension types so that we can focus on the most important changes.
For instance, we can have just a few critical changes located under some .cs files and many unimportant changes in our .csproj files. In such cases, we would like to see at one glance the modified .cs files.
I'm in a situation in which Collaborator has been configured to authenticate with LDAP (Solaris UNIX environment), our passwords are required to expire and be changed every 60 days, and we are using scripts which depend on one of those LDAP defined user accounts. I can't set the time-to-live to 12 hours, effectively require the re authentication of users each time they login, as that would expire the script user account every 12 hours as well. A special script running at a shorter interval so as to keep the script user account authenticated has been suggested, but it would be nice to have an internal collaborator account which was independent of both the time-to-live setting (has it's own?) and the external authentications PW expiration requirements, for running scripts.
Remove host/ip info from messages sent to users as it is in my opinion useless info and can be a security concern.
In our instance, the server is behind a reverse proxy. Users only know the url. The host info is registered in DNS to the proxy.
Sending the actual server's host info to the user on a password reset is meaningless and negates the purpose of the proxy to hide the actual server from the end users.
Submitted on behalf of Gadadhar Dalei (Wipro Limited).
Currently, Collaborator loads all users to the User List. If there are thousands of users, it may take considerable amount of time.
We have users that can no longer upload certain file types (for example, .SH, .BAT, etc. which do need to be peer reviewed) because they are restricted file types.
I understand the need for this feature and think it is a good idea to block potentially malicious files from being uploaded, however we are trying to figure out a good way to leverage this feature yet still accommodate users who need to upload and peer review these sorts of files. Renaming the extension to .TXT before upload is a workaround but doesn't work well when trying to upload from source control.
What would be great is if in addition to "Restricted File Types", Collaborator had an additional list of "Restricted File Types - Convert to Safe Format" that would automatically convert these files into a safe format - maybe by automatically adding at .TXT extension? This would allow users to peer review scripting-type files to the server, and protect the rest of the user community from potentially malicious uploads at the same time.
When I upload my code from Perforce to Code Collaborator the client tool allows me to "Create New Review" or "Add to Existing Review". "Add to Existing Review" pulls back all open reviews, including ones that are not relevant to me. Ideally the tool would also give me the option to filter this list to reviews that I am participating in (either as author/reviewer/observer/etc).
It's annoying when you're in a situation where there are significant amounts of open reviews to have to skim through to find yours.
The existing grid under the 'Review Materials' section is rigid. It does not allow the participants to quickly identify key changes.
For instance, a participant might have to scroll thru the a huge changelist to identify files having reworked changes or many affected lines.
Solution > allow the participant to sort the existing 'Status' and 'Changed lines' columns in descending order to focus on key changes.
Once a review has been created and participants provided comments, it will be nice for them to only show and focus on the files that have comments or defects. This can help them to spot the on-going discussions without scrolling up and down thru a huge list of files.
This could be implemented like the existing 'Overlay' toggle button that is located in the 'Review Materials' section.
Sometimes, you want a different person to look at something, or respond to a comment. My team would like Collaborator to have a capability to tag another user. For example, in Jira, you can use "@lastname,firstname" to tag another user. We would like a similar capability in the comment boxes.
When reviewing a submission (especially documents), it would be very useful to be able to report typos, spelling and grammar errors separately from more important higher-level feedback. Likely with buttons that would allow showing/hiding either type independently.
We've seen that people tend to not flag such small (but still correctable!) issues otherwise, because they don't want to take attention away from the big-picture feedback, drowning it out with the small things.
User experience would be greatly improved if the reviewer could associate their comment or defect to a range of lines instead of just a single line.
Additionally, if that range could also be inclusive of characters within a single line that would also be appreciated. When comments or defects are part of a large block of code being able to accurately call out an area of code instead of just a top line of code is helpful.
I've found that our CC instance had a significant amount of open reviews, some over two years old with no activity. Some were "false starts" where people had created the review but didn't upload files or add reviewers. I had to manually go to each and delete as there didn't appear to be a way to do that in bulk.
It would be great if there were a way to bulk or automatically delete open reviews older than a certain amount of time. Perhaps the system can notify review participants that the review is in danger of being deleted a week prior.
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).
Currently, when one creates issues and then sends to rework, the participant shows as "Approved" in the Participants module, which is highly confusing to our team.
Obviously the review did not approve this review as s/he submitted issues and sent to rework. The participant status should be "Waiting" or some new status "Reviewed", but "Approved" doesn't make sense.
Submitted on behalf of Brian Kingsley (Draeger Medical).
Need to be able to add the changelist_scmidentifier field to any report, e.g. "Reviews Currently in Progress".