Unequal state surfaces possible #182
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#182
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
The M2M attributes
after_states
andbefore_states
declare which biotope states existed before and after changes due to the data type (compensation, ema, ecoaccount).If the calculated sum of surfaces on each attribute differ from one another, the user is being informed on the detail view directly and again on a check or record action. Checking and recording of an entry is not possible as long as there is such a logical error on the entry.
However, there seems to be some irritation, since there can be valid situations where unequal before and after state surface sums exist.
First it needs to be determined (from experts) whether these situations are tuly valid or if there is a misunderstanding between users (from the past on the old system) and the experts.
Improvement
*An improvement will be formulated once the situation is more clear. *
Unequal stare surfaces possibleto Unequal state surfaces possibleAfter discussions with experts this issue is not an issue. The system must hold data on the surfaces before and after a change and they must be equal. The depiction of biotope surface usage might be a misunderstanding derived from the point based biotope calculation manual, published by the MKUEM.
Nothing to do here.