Quarterly Product Update | Camms.Risk Incident Management | Feb-Mar 2021
- amani imtiyas
Camms is pleased to bring you the Quarterly Product Release Note for Camms.Risk Incident Management.
This quarter we've got a number of exciting new features and enhancements to improve your user experience within the system, which was deployed to your Test environment on 20th March 2021 and will be deployed to your Live instance on 3rd April 2021.
1. Inheriting permissions from the parent object for an embedded documents object |
This enhancement will enable the permission of the parent object to be inherited instead of depending on permissions for the full 'Document Object'.
How do you configure this?
This is performed by configuring the 'Documents' field within another object in the workflow.
The Document Object can be configured within any other object in the workflow by enabling the ‘Is Enable Document Attach’ setting within the Field Configuration popup window (accessed via Incident Settings > Object Configuration > [select Object] > [select Field Object]).
This will then enable the documents object to be accessed via a Documents button.
How does this work?
Prior to this feature enhancement, documents were able to be added/edited/deleted via the Document button, only if you were given permission to the Document object in the workflow. Now, the Document object accessed via the Documents button, will inherit the permission of the parent object (i.e. the object in which the Document object is configured in), as well as the Document object.
If you do not have permission to the Document object, the Documents button will work within the parent object by inheriting the permission of the parent object.
If you have permission to both objects, the union of both permissions are considered and the higher permission will take effect.
Example 1: If the parent object (Incident Details), has add, edit, read-only permissions, and the Document object has only read-only permission, you will be able to add, edit documents via the parent object, based on the parent's object permission.
Example 2: If the parent object (Incident Details), has only read-only permission, and the Document object has add, edit, delete permissions, you will be able to add, edit, delete documents in the parent object, based on the document’s object permission.
Documents added via the Documents button can be viewed within the document object, configured to that field and within the documents object, based on the permission. However, it will not be visible if the document object is configured to any other fields in other objects.
Example 3: The Document object is configured for the field ‘Incident Title’ in the Incident object, as well as for the field ‘Investigation Status’ in the Investigation object. Documents uploaded against the ‘Incident Title’ field cannot be seen within the document object for the ‘Investigation Status’ field. But documents uploaded for both fields can be visible in the Documents object.
Notes:
The ability to ‘Add’ documents is inherited via the ‘Edit’ permission for all objects, except for the Incident object. For the Incident object, the 'Add' permission is inherited from the standard permission, ‘Standard Incident Add Permission’.
In order to ‘Edit’ or ‘Delete’ documents, the read-only permission must be given.
Important Note:
The existing behaviour of the ‘Read-Only’ permission for the 'Document' object has been updated with this release. The ability to edit the document by clicking the document title hyperlink has been removed. Now you are only able to view document details, and download all documents via the ‘Download’ icon.
2. Tracking the history of changes to users, user roles, and notifications |
This enhancement will let you track and display the history of changes in the Incident Settings pages for Users, User Roles, Standard Roles and Notification settings.
How do you configure this?
Users with the 'User Settings', 'User Role Settings', 'Standard Role Settings', 'Notification Settings' permissions (based on the page you wish to view history on) in the standard permission framework (accessed via Camms.Incident > Incident Settings > User Roles > [select User] > Permissions > [expand] Standard).
Or ‘Incident Settings’ permission in the new flexible hierarchy framework [currently in beta] (accessed via Camms.Risk > Administration > Role Management > Permission > Framework) to access the Incident Settings page, and then to access the relevant page under Settings, follow the same process as the standard permission framework, to view the history log of the relevant incident settings pages.
How does this work?
A history button will be available at the top-right corner of the following incident settings pages (accessed via Camms.Incident > Framework > Incident Settings):
User
User Role
Standard Roles
Notifications
Notification Templates
Once the History button is clicked, a ‘History’ summary popup window will display the following details:
User Name – Will display the user name of the user that made the change.
Time Stamp – Will display the date and time the change was made.
Changed Record – Will display the name of the record within the settings area that was changed (e.g. In the User Settings page this will denote the respective User Name).
Summary – Summary of parameters that changed.
History records will be sorted based on the time stamp column in descending order (lasted changed items on top).
Notes:
If you click on a particular record (eg: Username in the User page) and then click on the History button, the History popup window will display history data only for that record.
When there is no history data to be displayed, a message will indicate that no history data is available. (Eg. When there are no changes made within the Incident settings page or no changes made to a record after this feature release.)
For a detailed view of the changes made, click on a record, to take you to a three-tabbed page with the following details:
Summary – The first tab that is active by default, will display a grid with the columns ‘Field Name’ (only the parameter name(s) that have changed within the related settings page), ‘Current Value’ (the corresponding current values of the parameters that have changed), and ‘Previous Value’ (the corresponding previous values of the parameters that have changed).
Current Representation – This tab will display a grid with columns ‘Field Name’ (the parameter names within the related setting area) and ‘Value’ (the current value of the respective parameters).
Previous Representation – This tab will display a similar grid to Current Representation, with columns ‘Field Name’ and ‘Value’ (with the previous values of the respective parameters).
3. Removing the redundant incident my quick update menu item |
The Incident My Quick Update menu item has been removed as it duplicates the elements and capabilities available in the My Quick Update page. You can now access all assigned items under the ‘My Quick Update’ menu.
How does this work?
The ‘Incident My Quick Update’ option will be removed in the following areas:
Camms.Incident > Mega Menu > Incident Management
Camms.Incident > Administration > Role Management > [Product: Incident] > Incident Management
Camms.Incident > Framework > Incident Settings > Miscellaneous Settings > Configurable redirect for submit
The ‘My Quick Update’ option will be introduced in the 'Configurable redirect for submit' dropdown under miscellaneous settings (accessed via Camms.Incident > Framework > Incident Settings > Miscellaneous Settings > Configurable redirect for submit).
4. Enhancements to the Incident Master Report |
4.1 Updates to the report title of the report
The existing report title of the Incident Master Report has been changed to provide a clear definition of the report.
New Format: <Incident Code> Record Details
4.2 Depicting a hyphen for blank fields in the report
The Incident Master Report has been modified to depict a hyphen '-' instead of 'N/A' text, for fields with no data entered in the Camms.Risk Incident application.