User suggestions and feedback #86

Suggestions

After adding a related data, such as biotope or action on compensations, the viewport should jump directly down to the related data overview of a detail view. Otherwise one needs to scroll down each time a new entry has been saved and another one needs be entered.
1. Done
dal autocomplete window is way too short. This depends on the max-height value of .select2-container--default .select2-results > .select2-results__options, which is set to a default of 200px. This can be changed to e.g. 600px, which is a decent increase in size.
1. Done
Comment fields do not provide enough space (limit=200 characters). They should be changed to unlimited length, since very good entered data will be described in detail and that needs more characters.
1. Done
Use the comment field on a UserActionLogEntry properly
1. For EDIT actions, we want to see in the comment what has been changed (e.g. payment added, payment removed, deduction added, deduction removed, ...)
2. Display the comment field as detail on the log view of a dataset
  1. Consider renaming the comment attribute to detail for a more coherent naming/usage
Related data (CompensationActions, CompensationStates, ...) should be editable instead of delete and re-enter the correct data
Sent mails should have the title of the dataset next to the identifier.
1. Having the detail-view url of the dataset directly in the mail would also be very handy
Drop the revocation column on intervention index view in favor of a District column, displaying the districts in which the dataset is located
1. Find a neat solution to highlight an intervention, which has a revocation
Make major datatypes searchable by title in forms like new-compensation or deductions
~~Provide selectable KonovaCodes for COmpensationState or CompensationActions as downloadable file~~
1. Users want to share possible selection options with third parties, so they know directly the proper used terminology
2. see SGD-Nord/konova#86
LANIS Link for KOMs does not zoom similar to EIVs -> fix this
1. Check other LANIS links for a similar behaviour

# Suggestions 1. [x] After adding a related data, such as biotope or action on compensations, the viewport should jump directly down to the related data overview of a detail view. Otherwise one needs to scroll down each time a new entry has been saved and another one needs be entered. 1. **Done** 1. [x] dal autocomplete window is way too short. This depends on the `max-height` value of `.select2-container--default .select2-results > .select2-results__options`, which is set to a default of 200px. This can be changed to e.g. 600px, which is a decent increase in size. 1. **Done** 1. [x] Comment fields do not provide enough space (limit=200 characters). They should be changed to unlimited length, since very good entered data will be described in detail and that needs more characters. 1. **Done** 1. [x] Use the `comment` field on a UserActionLogEntry properly 1. For `EDIT` actions, we want to see in the comment what has been changed (e.g. payment added, payment removed, deduction added, deduction removed, ...) 1. Display the `comment` field as `detail` on the log view of a dataset 1. Consider renaming the `comment` attribute to `detail` for a more coherent naming/usage 1. [x] Related data (CompensationActions, CompensationStates, ...) should be editable instead of delete and re-enter the correct data 1. [x] Sent mails should have the title of the dataset next to the identifier. 1. Having the detail-view url of the dataset directly in the mail would also be very handy 1. [x] Drop the `revocation` column on intervention index view in favor of a `District` column, displaying the districts in which the dataset is located 1. Find a neat solution to highlight an intervention, which has a revocation 1. [x] Make major datatypes searchable by title in forms like new-compensation or deductions 1. [ ] ~~Provide selectable KonovaCodes for COmpensationState or CompensationActions as downloadable file~~ 1. Users want to share possible selection options with third parties, so they know directly the proper used terminology 1. see https://git.naturschutz.rlp.de/SGD-Nord/konova/issues/86#issuecomment-2579 1. [x] LANIS Link for KOMs does not zoom similar to EIVs -> fix this 1. Check other LANIS links for a similar behaviour

Rework Update

Reworks structure and visualization of CompensationAction and CompensationState and their related detail types
increases size of comment fields

# Rework Update * Reworks structure and visualization of CompensationAction and CompensationState and their related detail types * increases size of comment fields ![grafik](/attachments/1beb7942-2308-4853-84fa-723c76c7e641)

grafik.png

93 KiB

Parcel-Geometry improvement

No user feedback but due to the importance of this, the related commit has been put on this branch directly.

Problem

Our M2M relations between Parcel and Geometry are of high frequence and somehow temporary. Parcel-Geometry M2Ms will be recalculated regularly to ensure we always provide the most up-to-date information. This generates a huge amount of new/updated data all the time, meaning we may reach the sequential end of Integers in an uncomfortable amount of time. Switching to BigInt would be no proper solution as well, since BigInt has a limit as well.

Solution

We introduced ParcelIntersection as an intermediary model for the M2M relation between Parcel and Geometry. This model is based on the UuidModel, which provides a uuid field as primary key. Using uuids we will not just have a (nearly) unlimited amount of different primary keys, but also are able to 'reuse' uuids which once existed on this table, then have been removed, because the described relation was not needed anymore. This is not (easily) possible with sequences.

Migration

The migration files have been written and performed properly. This way we can make sure, that existing M2M relations will not be simply dropped and need to be recalculated (which would be possible of course) but instead will be migrated into the new model.

# Parcel-Geometry improvement No user feedback but due to the importance of this, the related commit has been put on this branch directly. ## Problem Our M2M relations between Parcel and Geometry are of high frequence and somehow temporary. Parcel-Geometry M2Ms will be recalculated regularly to ensure we always provide the most up-to-date information. This generates a huge amount of new/updated data all the time, meaning we may reach the sequential end of Integers in an uncomfortable amount of time. Switching to BigInt would be no proper solution as well, since BigInt has a limit as well. ## Solution We introduced `ParcelIntersection` as an intermediary model for the M2M relation between Parcel and Geometry. This model is based on the `UuidModel`, which provides a uuid field as primary key. Using uuids we will not just have a (nearly) unlimited amount of different primary keys, but also are able to 'reuse' uuids which once existed on this table, then have been removed, because the described relation was not needed anymore. This is not (easily) possible with sequences. ### Migration The migration files have been written and performed properly. This way we can make sure, that existing M2M relations will not be simply dropped and need to be recalculated (which would be possible of course) but instead will be migrated into the new model.

Providing of codelist download will not be added (for now). We should think about providing such a functionality for future enhancements of oKey.

Merged in #111

# Merged in #111

Labels Milestones