when a dynamic status triggers we now can trigger a notification (email or rest), we want to be able to also define triggers which for example:
- update a field (dropdown, append/prepend text on text|parragraph, set a date on a field, etc)
1 Like
Use case:
- i create a custom field on the policy module, with a drop-down with options 1, 2 and 3
- i want to update that field automatically to option 2 whenever the dynamic status “tralala” triggers
Use case 2:
- i created a custom field on my risks with drop downs with options 1, 2 and 3
- i want to set value 2 when risk is above 40 points
The trigger functionality has three components:
1- the logic that triggers the trigger
2- the items that will be affected
3- what fields on those items will be affected and how they will be affected
Now in detail:
1- the following three options can trigger a trigger:
- one or more dynamic status on / off
- change of risk value (analysis / treatment … this could only work with eramba and eramba multiplication formulas)
- change of value on an existing field (text field, dropdown, etc is changed to something new) … we need the comparisons based on the field type (text, dropdown, etc)
- when an item is deleted (we need this because for item creation you can trigger a dynamic status, but on the case of deletion is not possible)
2- the trigger can affect two things:
- the item that triggered the condition
- related items to this item (if you update a policy, you can trigger against that policy and all related controls … or all related control with status = blah)
3- you need to tell what fields on those items you will update and how you will update them:
- if its a dropdown, an option on that dropdown (careful, this should lock custom fields to prevent messing the db)
- if its a text field: append, prepend or update the field
Each trigger should keep a log (on the history functionality) that traces the three steps as they occur on the software.
the trigger functionality should be configured as another admin type of settings (acls should prevent the use or not) and set on the menu.
The user interface should let you load a modal where you define:
- title of the trigger
- the three conditions mentioned above
1 Like
We could perhaps let the customer run code (javascript) …
Another scenario:
We have a question regarding the Support Contracts section and its relation with Third Parties. Is there a way to know, when adding a Support contract, what type the third party is in the “Support Contract Supplier” field without needing to check in the third party section? This field contains suppliers and clients, and sometimes we have contracts with one company both as supplier and as client.