Features - brief overview
The full concept can be requested at ksp-servicestelle@sgdnord.rlp.de
The following brief overview presents the most important features, which are provided by the konova project. Due to the task of being the digital representation of the LKompVzVo, there are some legal constraints which have to be taken into account.
Data
In the following chapters we are refering to data
. This data has been called XY-objects in the past (~"Kompenationsobjekt", "Eingriffsobjekt", ...) which wasn't handy for people being technically uncertain. We simplifiy this by calling it (for this documentation) simply data
.
The different data types in konova are
Intervention
- "Eingrff" (~"Eingriffsobjekt")Compensation
- "Kompensation" (~"Kompensationsobjekt")EcoAccount
- "Ökokonto" (~"Ökokonto")Ema
- "EMA" (~"EMA")
The former process object
(~"Vorgangsobjekt") does not exist anymore, since it caused irritation among users due to it's unclear relation to intervention. The chapter "Viewing data" clarifies details on the process state
(~"Vorgangszustand"), which won't exist anymore as well.
Creating data
Data must be as easily addable and editable as possible. Therefore it is important to dismiss most of the mandatory form fields of the past. Data adding is a process, which can take up some time, since users need to aggregate their information, worst case from different sources. It must be acceptable to start with just a geometry and a title for the data and no further information. The user will come back to continue their work until they are done.
On the data's detail view it's getting clear which information is still missing despite the fact they are no mandatory fields on any form.
Sharing data
Sharing data between multiple users must be as easy as possible. Providing access to data is a well established method, oftenly found e.g. in cloud services of all kind. Therefore we adopted these ideas.
Sharing data using link
The user who created the data is always the first user having 'shared' access to the data. A share link
then can be created from the detail view of the data and be send to other people via e-mail which shall have access to the data. By clicking the received link, these users need to login and get immediately access to the data. The data is now 'shared' with this user.
This eradicates a big problem of the past: Access has been granted by inserting the proper organizations inside of the data, which were linked to users. In case of wrongly selected organizations -which happened a lot-, there was no way to undo this configuration as a user and an admin had to fix this issue by hand.
Sharing data using username
Furthermore users can be added directly, if their username is known. This way we can add the same users, we always work with together, directly without having the need to send an e-mail containing a share link.
Viewing data
As mentioned, sharing is the new way of providing access to data. In fact, we are talking about writing access the whole time. Data can always be seen by every user, but can not be edited directly. Each user will have their own index view of only shared data. This will be familiar for most users, since the successor did show only data, which should have been displayed for the user. But, as stated priorly, in case of wrongly entered responsible organizations for the data, there was no way to 'quickly take a look around' for the data not showing up in the desired user's index view. It was simply gone for this user.
Now, they will always see their shared data by default on the index views, but can use the filter section to toggle a checkbox for showing all, even unshared, data. This way they have reading access to all data in the system, if needed. Users then can search for their data and inform the one, who didn't shared it properly with them, to share properly.
Process states
In the past newly entered data had to pass multiple process states (~"Vorgangszustände"). These states were derived from the analogue administration world and could not be adapted digitally well enough due to users misunderstandings and uncertainty.
There are no process states in konova.
Instead the mandatory tasks, defined in the legal document LKompVzVo, are realized using the functionalities of share
, check
(see below), recording
(see below) and a flexible user group system.
User groups
User groups define permissions in konova. There are three main groups which a user can be related to. Each group provides the permission for using different functions in konova. A user without any group membership might be able to open konova, but won't be able to do anything.
Default
(~"Datenbereitsteller")- Can create new entries
- Can share entries with other users
Registration office
(~"Zulassungsbehörde")- Can perform a
check
on data (more in the related chapter)
- Can perform a
Conservation office
(~"Naturschutzbehörde/Eintragungsstelle")- Can perform
recording
on data (~"Verzeichnen") Recording
performs the same automatic checks on the data, ascheck
and marks the data asrecorded
using a timestamp, if no errors occured
- Can perform
Checking data
Checks are performed by members of the group Registration office
(let's call them ZB users in here - it's shorter). Checks are provided to mark data officially as checked
, so other users can see that some official took a look on the data. This way the LKompVzVo can be fulfilled: ZB users are generally in charge of the provided data. They need to make sure the data is consistent and correct. By checking
data, they are supported by some automatism, which checks the data on logical errors and inconsistencies. If the check was successful, the data is marked with a little golden star, so every other user knows that the ZB user did their job on here.
Use cases
Due to problems in the past, the checks are not mandatory. Users of the group Conservation office
(call them ETS users) can further process the data whether the check has been performed or not.
Checks
perform some automatic checks on the data, like all file numbers are provided, no inconsistency detected, and so on.
Checks
can not analyze the content of the data, which means the user still has to take a look on the data.
Checking compensations
Only interventions need to be checked. Compensations are checked, if their intervention is checked.
Reset of checked status
Past-check editing resets the check mark, so the check needs to be rerun afterwards.
Recording data
Recording (~"Verzeichnen") data works just as in KSP: ETS users can record data, which performs the same automatic tests in the background like checks and can be useful to detect flaws inside the data. However, by recording data, it is finally "official".
Recorded interventions are published if they are recorded and the binding date (~"Datum der Bestandskraft") has been reached.
Recorded ecoAccounts are published if they are recorded.
Compensations are published if their intervention is published.
Deleting data
None of the major data types (Intervention, Compensation, EcoAccount, Ema) will be deleted right away, if the user deletes
them. Instead, they will be marked as deleted, using a timestamp. This way they can be recovered at any time, in case the deletion was a mistake.
If data has not been restored for timespan x, it can be deleted automatically, to keep the database as clean as possible.
Editing data
Each data type consists of different smaller data types. Compensations for example contain geometry, dates, before-states, after-states, documents, actions (~"Maßnahmen") and so on. Instead of providing everything in a single large form, which needs to be loaded on every user edit, the user must be able to add and delete e.g. an action as easily as possible, directly from the detail view of the compensation. Therefore smaller, handy forms for each sub-data type must be provided.
User contact
Not being able to contact another user easily was a major problem of KSP. One user needed to clarify some thing about given objects but had no idea how to contact the initial data provider. If data has been shared with a user, it will be possible to see which other users have access as well. By clicking their usernames, a small window will open up, displaying basic contact details about the user: Person name and email.