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]).

Figure 1.1  Enabling the document attach setting

  • This will then enable the documents object to be accessed via a ‘Documents’ button.

Figure 1.2 – Attaching documents button available for field when creating an incident

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

Figure 2.1 – History button placed at the top-right corner of user settings

  • 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.)

Figure 2.2 – History popup window

  • 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).
      Figure 2.3 – History summary tab
    • 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).

      Notes: 

      • When the history field is ‘Permission’, the corresponding value will be shown in a comma-separated breadcrumb format. 
        E.g. If permissions ‘Standard Incident Add Permission’ and ‘Standard Investigator Permission’ under the ‘Standard’ category is enabled, it will be displayed as:

      Standard > Standard Incident Add Permission

      Standard > Standard Investigator Permission.

      • When there is no current data to be displayed in the 'Current Representation' tab, a message will indicate that no history data is available. (E.g. When a property is deleted)
      Figure 2.4 – History current representation tab
    • 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).

      Notes: 

      • When there is no previous data to be displayed in the 'Previous Representation' tab, a message will indicate that no history data is available. (E.g. When a new property has been created.)
      • Please note that when a property is edited for the very first time as well, the 'Previous Representation' tab will indicate that no history data is available. However, the 'Summary' tab will display any changes made to properties.
      Figure 2.5 – History previous representation tab
Notes: 
  • Changes to Incident Users performed via any integrated Camms.Strategy solution, will be displayed within the history of User related sections of Incident Settings.
  • Changes to Incident Users performed via any integrated Camms.Project solution will be incorporated in to the history of User related sections of Incident Settings in a future sprint.


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).
    Note: If you have selected the ‘Incident Quick Update’ option for the above configuration, you will be directed to the ‘My Quick Update’ page on submitting an Incident record.

Figure 3.1  Miscellaneous settings


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 

Figure 4.1 – Updated Title Format in the Incident Master Report 


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.

Figure 4.2  Improvements in the Incident Master Report 

Note: The Incident Master Report will be made available to all clients with the release of the above modifications to the report.