IT-Naturschutz/konova
7
1
Fork 0
Code Issues 6 Pull Requests 1 Actions Projects Releases 28 Wiki Activity

„concept“ hinzufügen

Michel Peltriaux 2021-08-11 09:51:24 +02:00
parent 689427d4e9
commit 73d851c0c4
1 changed files with 52 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
concept.md Normal file

@ -0,0 +1,52 @@
# Background
Due to technical as well as conceptional problems in the past and missing documentation, the konova project follows an underlying concept. This concept has been derived from the results of expert interviews and online surveys regarding the acceptance and usability of KSP as a modern eGovernment web application.
The results of this study can be requested at ksp-servicestelle@sgdnord.rlp.de
# Concept - brief overview
The full concept can be requested at ksp-servicestelle@sgdnord.rlp.de
The following brief overview presents the most important concept ideas, which are used as guideline for the konova project. Due to the task of being the digital representation of the [LKompVzVo](https://mueef.rlp.de/fileadmin/mulewf/Themen/Naturschutz/Eingriff_und_Kompensation/Landeskompensationsverzeichnisverordnung.pdf), there are some constraints which have led to the current form of the concept.
### 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
1. `Intervention` (~"Eingriffsobjekt")
1. `Compensation` (~"Kompensationsobjekt")
1. `EcoAccount` (~"Ökokonto")
1. `Ema` (~"EMA")
The former process object (~"Vorgangsobjekt") is no longer needed, as it caused irritation among users anyway. The chapter "Viewing data" clarifies details on the `process state` (~"Vorgangszustand"), which won't exist anymore as well.
### Sharing data
Sharing data between multiple users must be as easy as possible. Providing access to data using a `share link` is a well established method, oftenly found e.g. in cloud services of all kind. The user, who created the data, can create a `share link` and send it to other people, which shall have access to the data. By clicking the received link, the user needs to log in into the application and has immediately access to the data. The data is now "shared" with the 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, there was no way to undo these settings and an admin had to fix this issue for the users.
### Viewing data
As mentioned, sharing is the new way of providing access to data. In fact, we were talking about **writing access** the whole time. Data can always be seen by every user, but can not be edited directly. A user will have their own index views of shared data. This will be familiar, since KSP did show only data, which hold the user's organization. But in case of wrongly inserted organizations, there was no way to "quickly take a look around for the missing data". It was simply gone for the users. Now, they will always see their (shared) data on the index pages, but can toggle a checkbox for showing unshared data. This way they have reading access to all data in the system and can e.g. remind the user, who created the data in the first place, kindly to share the `share link` with them, so they can have access to the data.
This eradicates another big problem of the past, extending the one in chapter "Sharing data": Not only did the users had no access to their data - they could not even take a look on the data, to find the problems causing this issue.
#### Process states
In the past new data had to pass multiple process states (~"Vorgangszustände"). These states were derived from the analogue world and could not be adapted well enough digitally due to users misunderstandings and uncertainty. There **are no process states** in konova. Instead the tasks, defined in the 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.
1. `Default` (~"Datenbereitsteller")
1. Can create new entries
1. Can share entries with other users
1. `Registration office` (~"Zulassungsbehörde")
1. Can perform a `check` on data
1. `Checks` perform some automatic checks on the data, like all file numbers are provided, no inconsistency detected, ...
1. `Checks` can **not** analyze the content of the data, which means the user still has to take a look on the data
1. `Checks` are **not** mandatory for further processing of the data. In the past, there were users who did not continue their work, ignored it and so on. This way the data was simply stuck there and an admin had to continue the process.
1. `Conservation office` (~"Naturschutzbehörde/Eintragungsstelle")
1. Can perform `recording` on data (~"Verzeichnen")
1. `Recording` performs the same automatic checks on the data, as `check` and marks the data as `recorded` using a timestamp, if no errors occured
# ...