caseatmtr6
New Contributor
Joined 10 years ago
User Profile
User Widgets
Contributions
Possibility to mark a file as Accepted "As is"
Hi, During our review workflow (especially code reviews), reviewers often review a file and have no defect to formulate for this file. We would like to mark this file as "Accepted" or "Validated". This would mean this file does not has to be reviewed anymore in this review. This "Accepted" state should be reversible (clicking again on the button would invalidate the Accepted state) and this state has to be exported in reports just as defects. This way, by exporting review data, we would keep as a proof the fact that this file has been reviewed and that no defect has been found for it. RegardsAllow to click on an automatic link in a checklist item without checking it
Automatic links allow to associate a regular expression with an URL. It is interesting to be able to add links in checklist items using automatic links, to reference a document or a web site for example. Unfortunately, there is no way to click on an url contained in a checklist item without accidentally checking the item, except by opening the contextual menu and choosing "open". But the first reflex is to click on the link. It would be great to be able to click on the link without checking the itemRe: Provide server version to a client
Since new Web API, it is possible to get server version with JSON command [ { "command" : "ServerInfoService.getVersion" } ] But, it is not enough! What would be nice, is to get a variable substitution (sort of $server.id) that would allow inside a script fired by a trigger to know exactly what is the identification of the collaborator server doing that action (aka its URL).Re: How can one use triggers in Collaborator?
Hello, Not so difficult to set up. Take example on our Collab server. Server is connected to LDAP. Unfortunately, the only data people use to provide are just ID and password. It's not enough, we would like full name (as ID is provided by the company and is made of a letter and 7 digits, which is hard to identify persons) and email information as well. Furthermore, we decided to normalized the ID, having the first letter in lowercase... (knowing that windows is not case snsitive!) Hence, we looked at the available triggers, and there is one fired after the creation of a user. That's nice for our needs! So, the next step is quite simple. We wrote a shell script (our server installation is on Linux, but I guess that it would not be a great issue to write a script in whatever language, even within windows), called newUser.sh, and we provided its path to the trigger named "User created", with some parameter (for our case the only information we need is the ID used by the new user). Here is a screen capture for that: (Note: the 'ops' parameter exists because we have a second test server, and we would like the script to be able to differenciate the origin of the call (in order to send the modification to the right collaborator server :manhappy: ) The script by itself has not a big interest, I think, it prepares only the right argument to pass with the collaborator 'ccollab' command-line client. For our case we use the command 'ccollab admin user edit' with the necessary arguments (--new-login, --email, etc... - refer to the documentation) Well! Hope that helps in understanding the trigger mechanism... RegardsProvide server version to a client
Hi there, 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 :smileysad: 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! Cheers ThierryProvide color customization capabilities in DiffViewer
When comparing two documents in Collaborator, differences are highlighted in red and green in DiffViewer, which can be problematic for color-blind users. It would be great to add the possibility for each user to choose his or her own highlighting colors.
