Checked workflow improvements #163

Status quo

If an entry is checked (only relevant for interventions) it means the data is entered correctly. Checking is done by a registration office user with a simple button click.

Whilst an entry is only checked it still needs to be recorded by a conservation office user afterwards. Editing is still possible and might be done by the conservation or registration office user to fix some minor typos or add missing data.

If a checked entry is being edited, the entry will be un-checked, since there have been changes to the data, which need to be approved 'officially' by a registration office user.

Users are able to enable e-mail notifications on this scenario, where checked data is being unchecked. By default these notifications are not enabled on the user's profile to reduce the amount of sent mails beforehand.

Possible situations

Now there are some scenarios where this workflow might cause wrong interpretations:

Scenario 1 - Conservation office user edits

Assumption 1: Conservation office user has no registration office permissions

Data is being entered by the default user (e.g. architect offices)
Data is being shared with the registration and conservation office
Data is being checked by the registration office user
Entry is now checked
Conservation office user records entry
Entry is now checked and recorded
Conservation office user detects some minor mistakes on the data
Conservation office user unrecords entry, so it is editable and edits the data
Conservation office user records the data
Entry is now recorded but not checked

This scenario ends up in an entry which is recorded but the current state of the data is not checked, leading to the assumption the registration office didn't do their work on this entry.

However, the recording action still can be found on the entries history, proofing the registration office did their work.

Scenario 2 - Default user edits

Assumption 1: Conservation office user has no registration office permissions

Assumption 2: Default user still has shared access on the data

Data is being entered by the default user (e.g. architect offices)
Data is being shared with the registration and conservation office
Data is being checked by the registration office user
Entry is now checked
Default user detects some minor mistakes on the data
Default user edits the data without notifiying the registration office
Entry is now unchecked
Conservation office user wonders why registration office did not check the entry, yet

This scenario ends up in confusion between the registration and conservation office, since the registration office checked the data, which is not detectable as such anymore once the entry is being edited by the default user again.

Possible solution

If the entry is currently unchecked (doesn't matter why) and there is at least one recording action on the entries history, we could show the usual 'empty star' on the entry but next to it a gray-glowing star, indicating that there has been at least one check in the past but the data has been changed since then and it was not checked again, yet.

This solution could look like this on the overview table:

And like this on the entry's detail view:

A tooltip can be rendered when the user hovers over the gray star, which explains that the entry has been checked on date ABC by user XYZ but since then there has been changes to the data, which have not been checked, yet.

This explains all important details and the entry does not look like there has never been any checking-work been done by the registration office.

# Status quo If an entry is checked (only relevant for interventions) it means the data is entered correctly. Checking is done by a registration office user with a simple button click. Whilst an entry is only checked it still needs to be recorded by a conservation office user afterwards. Editing is still possible and might be done by the conservation or registration office user to fix some minor typos or add missing data. If a checked entry is being edited, the entry will be un-checked, since there have been changes to the data, which need to be approved 'officially' by a registration office user. Users are able to enable e-mail notifications on this scenario, where checked data is being unchecked. By default these notifications are not enabled on the user's profile to reduce the amount of sent mails beforehand. # Possible situations Now there are some scenarios where this workflow might cause wrong interpretations: ## Scenario 1 - Conservation office user edits *Assumption 1: Conservation office user has no registration office permissions* 1. Data is being entered by the default user (e.g. architect offices) 1. Data is being shared with the registration and conservation office 1. Data is being checked by the registration office user 1. Entry is now checked 1. Conservation office user records entry 1. Entry is now checked and recorded 1. Conservation office user detects some minor mistakes on the data 1. Conservation office user unrecords entry, so it is editable and edits the data 1. Conservation office user records the data 1. Entry is now recorded but not checked This scenario ends up in an entry which is recorded but the current state of the data is not checked, leading to the assumption the registration office didn't do their work on this entry. However, the recording action still can be found on the entries history, proofing the registration office did their work. ## Scenario 2 - Default user edits *Assumption 1: Conservation office user has no registration office permissions* *Assumption 2: Default user still has shared access on the data* 1. Data is being entered by the default user (e.g. architect offices) 1. Data is being shared with the registration and conservation office 1. Data is being checked by the registration office user 1. Entry is now checked 1. Default user detects some minor mistakes on the data 1. Default user edits the data without notifiying the registration office 1. Entry is now unchecked 1. Conservation office user wonders why registration office did not check the entry, yet This scenario ends up in confusion between the registration and conservation office, since the registration office checked the data, which is not detectable as such anymore once the entry is being edited by the default user again. ## Possible solution If the entry is currently unchecked (doesn't matter why) and there is at least one recording action on the entries history, we could show the usual 'empty star' on the entry but next to it a gray-glowing star, indicating that there has been at least one check in the past but the data has been changed since then and it was not checked again, yet. This solution could look like this on the overview table: ![grafik](/attachments/63689bd8-660a-4f7a-9c4e-7ff0badfb946) And like this on the entry's detail view: ![grafik](/attachments/08dc318e-cfca-4edb-a951-2e6a25f5b84d) A tooltip can be rendered when the user hovers over the gray star, which explains that the entry has been checked on date ABC by user XYZ but since then there has been changes to the data, which have not been checked, yet. This explains all important details and the entry does not look like there has never been any checking-work been done by the registration office.

grafik.png

26 KiB

grafik.png

16 KiB

Merged in #168

# Merged in #168

Labels Milestones