Scenario: A user has set up an observer role subscription for certain files or authors. This user is also a member of a review pool group. A review comes in where the observer subscription has taken effect and that user wishes to claim the review as reviewer. The user is unable to click the Action icon to automatically become a Reviewer. User has to Edit Users -> Modify their role -> Done Editing.
Proposal: Rather than require the reviewer to Edit Participants and change their role we feel that this review pool action should automatically convert a user's observer role to reviewer without it requiring a manual edit.
When creating basic automation for adding new changes to an existing review using the available api, I wanted to validate the user input; the first input is the review number, followed by TFS changeset number. So the command would be
add-review 1234 5678 - the first action is to validate if review 1234 actually exists; and this is where I got stock; collaborator does not have a basic is_reviewid_valid(reviewid) api; I can request to edit review 1234 (ccolab admin review edit 1234) but if this review does not exist collaborator suffers an exception - the exception results are then put on the console creating rather a nasty message - I would much prefer to ask the question is_reviewid_valid(reviewid) and get a True or False back, and take appropirate action based on the returned result.
Can you add this feature please?
We have developed an integration from a document-management system that uses one review custom field to store foreign document id and version information. When the review is created this information is provided from the other system through the JSON API.
Obviously we do not want the GUI Client users to change this field, but currently Collaborator does not allow this. To make life easier in this kind of use cases, I propose Collaborator admin section to have following extra (boolean) settings for review custom fields:
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).
We have some users with the same initials when using two initials, so have enabled the 3 initials. With three initials, it displays the second letter of the user's first name, but it would be useful to actually display a middle initial.
Therefore, could we have a per user field that allows custom initials to be entered, or in fact allows shortened tags per user to be used inside discussions in reviews?
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.
We're reviewing source code in a language that is not currently supported by Collaborator (Ada). It would be useful to be able to add a language syntax highlighting definition. There are other tools, e.g. Ultraedit, that do this with a simple text file that lists keywords against formatting options (colour, bold etc). The filename extensions are then mapped to the language definition.
Users should be allowed to change, or at least increase, the resolution of PDF files that are uploaded to a review.
When we were using PrintToReview, we had the ability to change the resolution of PDF files that we uploaded for review. This was useful when the default resolution was not easy (or sometimes impossible) to read. Now that PrintToReview has been made obsolete, we are no longer able to change the PDF file resolution when uploading the file, and this has caused us to reverto to manual reviews for some of our documents.
If a Reviewer (or Observer) is in the Approval state, then it is totally unnecessary, and indeed quite annoying and time-wasting, to have that reviewer taken out of Approval upon that reviewer being poked.
It would be much better, if Poking a user (via individual Poke or via Poking Everyone) left users in their state of Approval.
This would allievate issues such as:
1) Author clicks "Poke Everyone" (perhaps because several reviewers need to look at the review), but the unintended consequence is that it can throw a couple other reviewers out of Approval (thus wasting their time, because nothing else changed up to that point that would have otherwise thrown them out of Approval). Sure, the author could have individually poke only the necessary subset of users, but that less desirable alternative basically leaves the "Poke Everyone" button mostly useless.
2) Similarly, an Author may accidentaly poke a specific user; maybe missed the State column's claim that the user was in Approval and then miss-poked the user. Either way, it's the same downsides as above, but with no alternative via Code Collab.
In general, Code Collaborator has several annoying and time-wasting cases of throwing reviewers out of approval; this is one of them; please do fix! Thanks :-)
It would be useful to be able to organize review materials into something like a folder structure. E.g. to reflect the organization of source code packages or to segregate supporting reference material or checklists (that are not necessarily for review themselves) from actual review material.
Not sure if this already exists somewheer in the depths of the beast, but it would be nice to be able to set the review template to use for a new review based on the user group or name or some other user/admin configurable setting? even a default template for all new reviews.
Currently when you create a new review the default template used is often one which the users have no use for, and need to change, often after they have filled in a lot of details, so changing the template to use then resets the form.
This is not a problem for the reviews created by script as the template is clearly defined. But where the review is created from the GUI client or web interface, it uses a totally different review template by default, not even the old "Default".
Hi, I'm part of Technology Information Services' department of L.L.Bean, we currently use your code review application, and I have a suggestion that I think would be useful, we usually have issues with our team and code reviews, because we must have them done in a certain date, we usually use the description for point the deadline, so I think that 1 more field added to the information and the columns in the home page with that field will mean a great help, hope you consider it.
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".
If we want to configure the roles so that all comments must be read befor the review can be closed then the automatic generation of unread "Marked review action fixed:" comments forces another time-wasting back-and-forth between the author and reviewer before the review can be closed. It would be great if the "Marked review action fixed:" comments could be generated as being already read or alternatively not included as unread comments when determining whether the review can be completed or not.
The sequence of events that causes the scenario are as follows (with the roles configured to require reading all comments):
1) Reviewer creates an action item in a review.
2) Author addresses action item and uploads a new file.
3) Reviewer marks the action item as fixed and in doing so a "Marked review action fixed:" comment is automatically added to the review. The review is effectively finished at this point but the reviewer is unable to approve the review because there is an unread comment (the "Marked review action fixed:" comment) that the author needs to first mark as read. This is the problem.
4) Needlessly the author goes must now go back and load the review to mark all of the "review action fixed" comments as read. If there are a lot of files in the review this has to be done manually for each file. Also, if there happen to be additional comments left by the reviewer along-side the "Marked review action fixed:" messages then the author needs to sort through all of the useless "review action fixed" comments to try and find the useful comments.
5) The reviewer now needs to go back and open the review to do nothing more than click the Approve button which could have been done in step 3 if the "Marked review action fixed:" comments weren't automatically generated and marked as unread and weren't preventing the review from being closed. For our use-case this extra step is both a nuissance and a waste of time and therefore we cannot configure the roles to read all comments even though we would prefer to have the roles configured that way.
It is helpful to see who actually created the ticket instead of having all of the tickets created by the user configured in the external integration screen.
Many of the users of the Collaborator application in my company want to use it to review changes made to Microsoft Word documents. However, the document Diff Viewer provided with Collaborator does not have the ability to "understand" the word documents in a their native format - as it first converts them to text files and then displays them as PDF files. Thus, the "context" of the changes is lost.
For instance, users would like to be able to ignore differences in versions of word documents caused by mere changes to document Header and Footer page numbers, for instance. This type of filtering is not provided by Collaborator's diff viewer, since it treats all differences between 2 Microsoft word documents the same (as basic text), whether they come from differences in body text, header text, footer text, table of contents text, etc.
Also, is there a way for Collaborator to see/create something similar to the "Document Map" that is provided in Microsoft word - this would simplify document navigation because then section numbers of the document could be navigated to directly. Also, if the section numbering, header, footers, body text, TOC of the document provided in the open xml format (namely the docx file) were parsed by Collaborator's Diff Viewer, and some functionality created to allow the Diff Viewer to potentially ignore changes in files caused by updates to Table of Contents, Header, Footer text, etc. Currently, this type of filtering of word document changes is not possible in Collaborator's file Diff Viewer. It would be nice if add-ins could be provided that would provide this type of functionality.
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.
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.