Improve check/record reset #140

New Issue

mpeltriaux · 2022-04-08T09:20:18+02:00

mpeltriaux commented

2022-04-08 09:20:18 +02:00

Status quo

An entry's check/record state will be reset if any data will be changed afterwards.

Improvements

Ignore this, read the new improvements approach

~~There are use cases where this logic would not be practical:~~

A deadline is added/edited/removed
1. A user could add further details on a deadline or add a new one. This should not affect the current check/record state
The comment is edited
1. The comment should be editable without affecting the check/record state
2. Therefore there should be a more detailed validation on what changed if an entry is edited: If only the comment has been changed, the check/record state should not be resetted

New improvement

Instead of any overengineering, we focus on a simple but effective and understandable solution:

Simply prohibit any adding/editing/deleting of data whilst the data is being recorded.
To inform users properly, which want to edit a currently recorded entry, the users should be redirected to the detail view or - in case of a modal form - the form should contain simply a message stating that editing is not possible as long as the data is recorded.

This is understandable. This is simple. The full power goes to the ETS user.

# Status quo An entry's check/record state will be reset if any data will be changed afterwards. # Improvements **Ignore this, read the new improvements approach** ~~There are use cases where this logic would not be practical:~~ 1. A deadline is added/edited/removed 1. A user could add further details on a deadline or add a new one. This should not affect the current check/record state 1. The comment is edited 1. The comment should be editable without affecting the check/record state 1. Therefore there should be a more detailed validation on what changed if an entry is edited: If only the comment has been changed, the check/record state should not be resetted # New improvement Instead of any overengineering, we focus on a simple but effective and understandable solution: Simply prohibit any adding/editing/deleting of data whilst the data is being recorded. To inform users properly, which want to edit a currently recorded entry, the users should be redirected to the detail view or - in case of a modal form - the form should contain simply a message stating that editing is not possible as long as the data is recorded. This is understandable. This is simple. The full power goes to the ETS user.

mpeltriaux added the

enhancement

label 2022-04-08 09:20:18 +02:00

mpeltriaux self-assigned this 2022-04-08 09:20:18 +02:00

mpeltriaux commented

2022-04-14 14:18:18 +02:00

As stated in SGD-Nord/konova#146 (comment) we should not forget to focus on KISS: Keep it small and simple!

Instead of differentiating between different types of "important" or "less impotant" attributes, where the same actions end up in different results, we need to keep it small and easy and understandable for everyone.

We may follow the idea from the other issue:

If an entry (does not matter what) is recorded and a user (does not matter which group) tries to add/edit/delete data, the proper form or modal form will not show up but instead a message, that the entry can not be edited as long as it is still recorded. This way we would force the ETS users actively to verify the unrecording, then check on the edited data and record it manually afterwards again.
If a user tries to open the general data form of an entry, we could simply redirect back to the detail page, stating that editing is not possible, whilst the data is recorded. The modal forms could render the same message as well instead of the regular modal form content.

This way the ETS is completely in charge in the end: If anything shall be changed after recording of the data, an ETS user first needs to unrecord the entry, so it will be gone from public visibility. Having enough info and messages on any tried edit action on a recorded entry, we surely will keep this as understandable as possible for anyone.

As stated in https://git.naturschutz.rlp.de/SGD-Nord/konova/issues/146#issuecomment-3113 we should not forget to focus on KISS: Keep it small and simple! Instead of differentiating between different types of "important" or "less impotant" attributes, where the same actions end up in different results, we need to keep it small and easy and understandable for everyone. We may follow the idea from the other issue: >If an entry (does not matter what) is recorded and a user (does not matter which group) tries to add/edit/delete data, the proper form or modal form will not show up but instead a message, that the entry can not be edited as long as it is still recorded. This way we would force the ETS users actively to verify the unrecording, then check on the edited data and record it manually afterwards again. If a user tries to open the general data form of an entry, we could simply redirect back to the detail page, stating that editing is not possible, whilst the data is recorded. The modal forms could render the same message as well instead of the regular modal form content. This way the ETS is completely in charge in the end: If anything shall be changed after recording of the data, an ETS user first needs to unrecord the entry, so it will be gone from public visibility. Having enough info and messages on any tried edit action on a recorded entry, we surely will keep this as understandable as possible for anyone.

mpeltriaux referenced this issue from a commit

2022-04-19 14:04:34 +02:00

#140 Block edit on recorded

mpeltriaux referenced this issue from a commit

2022-04-19 14:04:34 +02:00

#140 Enhancements

mpeltriaux referenced this issue from a commit

2022-04-19 14:04:34 +02:00

#140 Tests

mpeltriaux referenced this issue

2022-04-19 14:06:38 +02:00

140_Improve_check-record_reset #152