Feature - review process of risks, policies and assets

Phase #1 Changes on the Review Module: Basic Review Settings

  • we need a setting on the Asset/Risks (all three) and Policy module under Settings/Review where people can choose on a multiple select dropdown that lists all roles in the module (there could be custom roles too) which ones inherit by default review records.

  • the field is called “Review Inherit Role” (Select one or more custom roles that will inherit by default review records created for items in this module. Modifications to this setting will trigger updates to all existing, incomplete reviews to reflect your changes).

Note: if the user creates. a custom role, it should be displayed as part of the drop down menu mentioned above.

Exception #1: currently on the risk modules, the “GRC Contact” inherits reviews, this needs to be changed to “Risk Originator Contact” role. This applies to new installs only. Past installs will have the “GRC Contact” as reviewer (same as today).

Exception #2: currently on the asset module, we miss a mandatory role for the “GRC Contact”, when we create this field it needs to be automatically populated with the “Admin” user on the migration. The default reviewer for Assets will be the “Asset Reviewer” (please rename this to new and existing installs to “Asset Reviewer Contact”).

  • Default value for NEW INSTALLS are listed below. Existing installs keep the settings we have today.

    • Assets: Asset Reviewer Contact (this is a change from what we have now
    • Risks: Risk Originator Contact (this is a change from what we have now)
    • Policy: Policy Reviewer Contact (this is a change from what we have now
  • When you edit the parent item (all three types of reviews) and modify the selections on the dropdown of a custom role, this should trigger an update on the reviewer field on all incomplete, future reviews.

Github: https://github.com/eramba/eramba/issues/4652

Phase #2 Changes on the Review Module: Review Form Simplification

  • we need a default status called “Completed” when a review is “completed”, this applies to all three types of reviews.

  • make sure the status “Current” review is applied to the one that has the latest “Actual Date” and is “Completed”. You could easily have more than one review with the same “Actual Date” so always assign the current to the latest of those records (i guess the id of the item?). Every time a review is edited, deleted or added this status should be re-calculated. The same every time the daily cron runs.

  • Remove the “Completed” option, no-one is using this and is very confusing. Assume all reviews are “Completed” when “Saved”.

  • the form today is a bit different, depending if you are editing an existing review or creating an “Ad-hoc” review (when someone clicks on “Actions/Add”). The following changes are needed when editing an existing review:

    • when we edit an EXISTING review, we just need to get rid of the completed option, assume is “Completed” always.

  • The following changes are needed when an Ad-hoc review is created (Actions/Add)

    • We should not let people create add-hoc reviews (this are created when they click on action/add or click on the option below) if there is an existing “Expired” review. “Expired” means that there is at least one (could be more) review that has a “planned date” in the past AND is “incomplete”. The message should say: “You currently have expired reviews, please complete those before creating new review records”

  • when we create a new review (Actions / Add), the “planned” and “actual date” fields should show todays date by default and should be disabled, the user can no longer modify these dates. you can still show these fields to the user (read only)

  • the “completed” option should go away as discussed before, by default is “enabled”

  • when you add a review (Actions/Add), the “next review date” TAB should disappear if there is an already EXISTING incomplete review with a “planned date” in the future for this item. If there isnt one, then you show it.

  • TO REVIEW: you should be able to bulk edit reviews (all three types), i understand that when you edit a review some fields are automatically completed so when you bulk edit you need to have the logic to ensure all required fields to save a review (indiferent of which one you are editing) are mandatory. the question is, does bulk edit feature today have the form logic embedded? i think not.

Phase #3 Changes on the Review Module: Activity Log Records (NOT YET DECIDED)

  • when you start the review of a risk as a stakeholder, you see this … how can i see what the risk is if i just see a row? we need an “Item Report” to be available to the user on those review records. Today the “Item Report” applies to the item, but in some cases these items have a “Parent Item”, so we need to be able to display those as well for the user, a little like we do with Activity Log.

  • The parent item report should include a “Table” widget that can lists all activity logs on the item. If i try today to create a table with that information on the “Parent” item i get the following options only, we need here to be able to include Activity Log records. This feature should apply to all modules where activity logs are available.

  • when you create a warning notification or comments & attachment notification or an awareness notification, because they always trigger in relation to an item, you could include to “Attach item Report” (The email will include a PDF with the report of the item that triggered this notification) of the item that triggered the notification, the user here would select from the list of available “Item Reports”. that option is ONLY available when they choose “Email Notification” (not webhooks). Of course, item reports can not be deleted if they are used in any notification, we need to block those actions.

  • when you have items that have “parent” / “child relationships” , on the parent item, a new activity log record should be created when an child item is created.
1 Like