Release Notes

All platforms - Desktop, Gluon: Improved handling of purged revisions in the GUIs

Several views can now detect a purged revision.

In the views that show a list of revisions (such as the History view) the purged revisions now have a trash icon and a different visual style. A tooltip also indicates purged revisions from the list.

In the Differences view, a message indicates the revision was purged. This Differences view appears in different places within the application: the History view, the Diff window, the Code Review window...

All platforms: Restrict code review status changes to reviewers

From now on, only a reviewer will be able to update the review status.

When there is no reviewer assigned to a code review, the GUI will allow updating its status by any user, as before.

All platforms - Triggers: The "edit review" trigger includes the reviewer edition action

Now, the add reviewer, update reviewer, and remove reviewer actions also run the edit-review triggers and set the following info on the PLASTIC_REVIEW_ACTION and PLASTIC_REVIEW_ACTION_INFO variables

* Add reviewer

** PLASTIC_REVIEW_ACTION -> add reviewer

** PLASTIC_REVIEW_ACTION_INFO -> James

* Remove reviewer

** PLASTIC_REVIEW_ACTION -> remove reviewer

** PLASTIC_REVIEW_ACTION_INFO -> James

* Update reviewer status

** PLASTIC_REVIEW_ACTION -> update reviewer

** PLASTIC_REVIEW_ACTION_INFO -> James:Reviewed

All platforms: Server-side merge takes into account the exclusive check-out rules

Before, the server-side merge (merge-to) operations ignored the exclusive check-out rules (lock rules). This happened both for Smart Locks and the legacy lock system. This misbehavior could lead to file conflicts although the lock rules were in place.

Now, the exclusive check-out checks & operations run from merge-to too. The operation now behaves the same as if you run the merge from the client side, and can not lead to file conflicts.

All Platforms - Client Command Line: The cloaked configuration is now taken into consideration in encrypted organizations

When working on an encrypted organization, the encryption key is stored in the client for security reasons - it never reaches the server.

Because of this, the server could not apply the cloaked filter stored in the server (apply the cloak before even attempting the download). It could only use the cloaked filter stored in the workspace, which could be out of date.

Now the server can read the cloaked.conf stored in the server without compromising the security. For encrypted organizations, the client first downloads the cloaked.conf in the server. This way the client can use the latest version, regardless of its encryption status.