Minor improvements #146
Labels
No Label
backlog
bug
duplicate
enhancement
feature
help wanted
invalid
question
wontfix
bug
duplicate
enhancement
help wanted
in discussion
invalid
priority
1
priority
2
priority
3
priority
4
priority
5
question
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: IT-Naturschutz/konova#146
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Status quo
There are various minor tasks, that should be improved/fixed:
Team sharingTeam leaveQR codes clickableRecorded entry editingExtend output for updateallparcelsGeometry adminDefault rpp on overview5. Edit->unrecord log comment
Whilst working on this task, I was wondering why should we even allow any editing on a recorded entry?
Wouldn't it be more predictable for a user, if instead of a (maybe unwanted) automatic unrecording of the data, we simply prohibit any editing whilst being recorded?
This approach could look like this: 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 should be thought through carefully and result in a new issue.
Merged in #150