Ideally the user would be able to define their own custom roles (maybe the user wants more or less thans the one we use, but that change goes too deep into eramba and … is well, really not something we want to get into)
The user should be able to define the status label name
the user should be able to define the logic that triggers the status , probably add or remove status too. So the logic for “expired review” now is that the last review is incomplete , the user could define another status called “Very very expired” where the last 3 reviews are expired. Some sections dont even have status … for example "when a risk is “closed” , how do i tag that?
the functionality is then composed of the following elements:
user defined “Status” , examples are “Failed”, “Pass”, “Open”, “Closed”, etc. these are the drop downs you see in most sections. the immediate gain is that you can now group items as you wish (risks no longer applicable, audits that are not failed or pass … but are more less ok, etc). this means new reports can be created immediately too as you can group items based on this status you define.
user defined “Dynamic Status” , which trigger based on the “status” and sometimes a date. The user will be able to define their own dynamic statuses (name, colour and conditions). Reports, filters and notification macros will then reflect these settings
Drop down with the list of functions (see the list of functions on the spreadsheet). Functions return: date, string and integer…when a function is selected its description is shown below to make sure the user understand what the function does
Operator (depends on the function selected)
string: = ! contains
date: on, before, etc same as filters
Value (depends on the function selected)
integer: the user provides an integer value
string: the user provides a string or regex
date: the user provides a static date OR a reference (+14, -7, etc)
How does this work for a system admin?
the user can define their own “status” on top of the ones eramba ships with - these status can be enabled or disabled (if they are disabled they stop showing on the form, users can not disable a status that is being used on a dynamic status)
the user can then define dynamic status, these definitions use operators, hardcoded functions and in between the rules “Ands” and “or”
every time a dynamic status is “saved”, the entire section (and all its related sections) must be re-calculated. since this can take a while we need a warning (a bit like on the login page) to be shown until the recalculation is completed.
Reports must be updated on the sections that support dynamic status, i would suggest we re-use the existing charts but update the group by and colour based on the definitions of the setting.
Notifications remain the same except for those that trigger when a specific status is identified, see the spreadsheet for details.
Macros must be reviewed to understand where this is affecting them, they will need to become dynamic too.
You can use custom fields for the time being, remember fields are now totally configurable (name, helper text, etc) hopefully giving you a little bit more of customisation. our aim is this year to make as configurable as possible…so there will hopefully be many changes in this direction
the addition of customizable “status” will come this year, for sure, just not now