mtalexan
Senior Member
Joined 8 years ago
User Profile
User Widgets
Contributions
Review Pool Subscriptions duplicate additions (unusable)
As of Collaborator 11.1, the file subscription mechanism for review pools has a bug that makes it unusable by adding many duplicate Review Pool slots to reviews. We have three types of file filters that need to require a single member from a specific review pool to review the changes. What we get is an entry for the review pool in the participant list for every file matching each of the filters. So for example, our review pool is intended to watch Makefiles. We have review pool file filters for: **.mk building/* Makefile If a user adds: Makefile, building/somefile.mk building/someotherfile.mk We end up with 5 review pool participants. One for each of the files matching the first filter, one for each of the files matching the second filter (even though the same files were already matched by the first filter), and one for the third filter. The issue seems to be in the implementation of the participant file filter is implemented. With most users it blocks subsequent adds because you can only have a review on the review in one role. Theoretically it does some comparison to promote the participant role when duplicate roles are requested (I've never tested it). With Review Pools, it's possible to add the same pool multiple times, so the logic that blocks duplicate additions to the same review doesn't apply/work.1.2KViews0likes0CommentsRe: Create new participant status for send to rework
As of 11.1.11101 (possibly sometime recently before this version), the status now shows as "Rework" instead of "Approved" in the participant list based on the button that was actually clicked. This seems to be purely based on the current state of the review, not on the state when the user clicked the button though. If all Bugs/Defects get marked as completed after the "Send to Rework" was clicked by a user, and no additional files were uploaded, the status of all the reviewers who have completed reviewing is automatically changed to Approved. It's up to the reviewer to have set an appropriate notification event that would revoke their status.1.2KViews0likes0CommentsMake the "Approved" state of a file more obvious and better named
There's an undocumented (or poorly documented) feature that participants in reviews can mark revisions of files as "approved". This effectively bookmarks that version of the file for that specific participant, and also indicates all other participants that the file has been reviewed by the individual. This plays into the per-user setting of the default comparison view of "Last Accepted vs Latest". The feature is: 1. Poorly named. Reviewed does not mean accepted, it means it's been looked at . Subsequent changes may still be necessary, but I might not want to have to review everything from scratch again just to see if the one defect/bug was fixed. 2. Not obvious: Clicking an un-named checkmark button in the file view, but only on the overall discussion of the file, shouldn't trigger completely different behavior from the same button on any other part of the file. 3. Not documented: Only because I clicked it accidentally did I even discover it showed up on the Overall materials section. Through playing around with it did I discover what it did as a bookmark on that version of the file. Since it's not self-documenting (see #2), it should either be fixed to be self-documenting or much better documented in the user guide. I would consider this a major killer feature, and it's almost completely hidden. Suggested fix would be separate it from the File Overall discussion into a separate button. Something called "Mark Version as Reviewed" or something similar. Then use a different icon so it's not confused with the non-functional "Accepted" checkmark button that currently also appears on every comment/bug.1KViews0likes0CommentsRe: Show state as "Waiting (was approved)" or similar
Somewhat like tlhobbes described, but applied to the top level review page, when a user clicks the Send to Rework/Complete button, I think it should log that to the Overall chat box. If you're curious about this information, it's then available even after different changes might be uploaded. The first response by tlhobbes to his own request does seem to address the basic problem though. There's an undocument (maybe just poorly documented?) feature that clicking the checkmark button on the File-specific Overall will mark that file as "approved" and effectively operates as a bookmark of the last file state an individual reviewer has looked at. Doing this does create a log on the File-specific Overall of the reviewer's name, and that they "accepted" it.6.5KViews0likes0CommentsGitHub/GitLab Integration: Selectable default template by project
When a Collaborator review is created from a pull/merge request through the GitHub/GitLab remote integration, it would be nice if a template could be configured to be automatically selected based on the project the pull/merge request came from. Different projects may have different workflows, so setting a default template for the Collaborator review based on the project would set the proper workflow. Currently the default template is the last one the user creating the review (which is matched from the user creating the pull/merge request) used.Re: Implement sync of GitHub pull request reviewers and Collaborator reviewers
In general the GitHub/GitLab integration needs to be more granular in my opinion, and options are needed for what to pull across from a merge/pull request triggering a Collaborator review to be created. This would be an extremely useful option that could be independently selected on a per-project basis. What isn't clear is the role these Approvers should be given. GitHub/GitLab doesn't have roles for Approvers, while they're critical in Collaborator. The roles available are different between templates in Collaborator, so what role should these approvers be given?4.1KViews0likes0CommentsRe: Allow reviewers to quickly filter the file list by file type
Effectively this is what GitHub and GitLab implement for their "diff" view (if I'm understanding correctly). Basically a dynamic page that allows text to be entered into a filter box and provide real-time filtered results in the file list/materials section.5.3KViews0likes0CommentsRe: Allow to pre-fill the 'Before' and 'After' branches in Code Collaborator Client
If you're running the review generation "systematically", I could recommend using the "ccollab" tool rather than the "ccollabgui" tool. You can manually provide the necessary details directly from the command-line rather than having to run the settings through a GUI. If you wanted advanced GUI modification, I would expect you to roll your own custom GUI wrapper to the ccollab command-line tool since the one already provided is just a simple wrapper to begin with. For example I'll usually post a review as: ccollab addgitdiffs new master...my_feature_branch I wrote wrapper scripts that could take more or less options for my use cases, and if I'm uploading to an existing review I would replace the "new" keyword with the review number.3.7KViews0likes0Comments