Would like the ability to set a deadline for the entire review (mainly for author) and the ability to set a deadline on when the document has to be reviewed by the reviewers and observers. Would be pretty cool if the document could be locked for comments after the reviewer deadline has passed.
Add a new field type that allows you to select someone from a list of users invited to participate in the review.
For example, sometimes we log defects on behalf of someone else (for example, if during an in-person review with a recorder), so we currently work around this limitation by including a text field where you manually type the name of the person who raised the defect.
Also wondering if there would be value in providing the option to select from a list of all collaborator users (not just the ones added to the review).
Web-based Code Collaborator has been a great tool for us! We spend a lot of time with it. But that is also a curse: can you help us spend less time with it, by providing keyboard shortcut keys for frequent reviewer actions (such as these listed below)? Extra points if the shortcut keys can be configurable (perhaps in Settings?), but I understand that beggars can't be choosers. Of course, the tooltip hint should reveal the shortcut key.
Speed/ease of use has been an obstacle to Code Collaborator adoption for some of our team. Thanks for considering!
would it be possible to add the ability to add comments to a checklist item per reviewer when that item is checked
The system tray application is very handy; one small improvement could be made with the tooltip - currently the toolltip says "you have X action items", which really just translates to the number of open reviews you are participating in, but doesn't let you know at a glance how many reviews require your attention (see below).
A more useful tooltip would be something like "X open reviews, Y need your attention (Z overdue)", where X would be the number of open reviews you are participating in, Y would be the number of reviews where you are not currently in waiting / approved status, and Z would be the number of reviews that need your attention, and are past the review's configured deadline date.
Correspondingly, it would also be nice if the system tray icon changed to reflect various status, for example a green indicator could indicate 0 reviews requiring your attention, yellow indicating 1+ reviews requiring your attention, and red indicating 1+ reviews requiring your attention that are overdue.
This issue came to my attention when I found that the Participant Custom Field Multiselect box is always mandatory. It doesn't matter if you have Due By/Visible By set to a value or not. If you are using it, it is mandatory. That is not how I want it to work. I have seen something similar on other fields where you put in validation, and it makes the field mandatory. I don't necessarily want it to be mandatory, but if it is used, it should follow a certain format. I would like to be able to specifically define if a field is mandatory or not. It could be visible and not mandatory, visible and mandatory, and it may or may not have validation or selections.
Collaborator provide support for Github repository. As Stash is based on git as well, hence most users expect that Collaborator will have support for Stash as well. However, with latest version of Collaborator, this feature is not there.
On interaction with their support team, I was informed that this feature is on their card, however they have not given specific timeline.
Kindly vote this new idea up so that, request for this feature can be taken on priority.
Thanks and regards,
It will be better to have a single report for which I can add any type of field from the review, along with the specific attributes for a issue: like position, severity etc.
At this moment if I want to extract the reviews created by a specific user, no matter the status, with the number issues and their severity, I can't use a single report, I need to go first on Review Currently in Progress, then on all issues.
The report section is important and help us track the status for each project.
Users should be able to select SCM (CVS) files for review from the Web User Interface.
Everyone uses the Web UI to conduct reviews. But right now users have to use the Client GUI to get CVS files onto Collaborator. This is yet another product we need to train people on, and a separate program we have to install on each user’s PCs.
SCM should be integrated into the Collaborator UI. This will concentrate the interface on one product, without additional apps installed. SCM settings could be under each user’s personal settings tab. “SCM file” could be an option under Upload.
The benefit will be an integrated product with a consistent user interface.
Currently, detailed reports do not keep track of changes to the reviews themselves.
After you create (begin) a review, changes such as adding or removing attendees, changing review title/description/custom fields are not recorded anywhere. For accounting and Quality purposes, having a log of review attribute changes is helpful to have around.
I frequently keep one browser (on Windows) open to a review I am creating using the Linux GUI client to upload files to the review. Uploading from subversion workspace might take a number of uploads from various project root directories. I am always dismissing the browser after the launch of each one. It would be nice to have a persistent preferences setting to speficy whether or not to launch a browser after uploading.
While scripting for Collaborator administration tasks (like triggers), I was disappointed not to have an opportunity to get directly the server version from a command to the server with the ccollab utility; I was obliged to write down inside the script that reference, knowing that I will have to modify it at next server upgrade
Thus, would it be a so big evolution to propose, in a future release, a command option (e.g. 'ccollab version' or 'ccollab admin version') that returns the server build number to the client utility?
It would be a great help. Thanks!
Would it be possible to find an easy way to let to Reviewer know which files have been updated in a review? Right now the Reviewer must click on the files to see what has changed. Could the "added/changed/deleted" numbers be a difference from the last reviewed/accepted revision as opposed to a running count of all modifications to the file? Even a visual indicator like (*) next to updated files with changes from the previous reviewed/accepted would be sufficient. As things are now, it's a really chore to review code using Code Collaborator.
On large reviews, it can be hard for a reviewer to track which files they've completed reviewing, if there are defects or discussions still ongoing. In that case, you don't want to mark the file as accepted, so it would be nice if there was a "Review completed for this version" button or flag.
Additional notification schemes that can be set by user is requested. Even "minimal" is too much for some people, and they would like "minimal minimal". What specifically has been requested is to receive email when the review changes state only. Others may have different ideas when they want to receive emails.
Ran into an interesting bug/feature this morning. We have some reviews that are suddenly failing their integrity checks.
When a review is in this state, it seems that the Home/Action Item screen (WebUI) for users who are a part of that review will never see their action screen load, even though it does contain other valid reviews. The screen jut says “loading” and will sit in that state.
Would be nice if the Home/Action Item screen had some kind of flags or timeout value so that valid reviews could still be displayed. (and in a perfect world, also display the failing reviews in another color so we know something is up)
Our subversion server is configured to use authentication - each user has username and password which (s)he uses. Each repository and directory on the server have different access rules, so that each user can see only those sources that he has authorization for. Now as collaborator is setup to use a single username/password when accessing svn, this creates a hole in the authorization scheme. Each user who has access to collaborator can use collaborator to access sources in every repository and directory collaborator has access to.
A proposed solution: Make collaborator ask for svn username and password when uploading sources from subversion.