„features_en“ ändern
parent
ea7f253669
commit
d53a741594
@ -1,4 +1,3 @@
|
||||
|
||||
# Features - brief overview
|
||||
The full concept can be requested at ksp-servicestelle@sgdnord.rlp.de
|
||||
|
||||
@ -19,6 +18,7 @@ The former `process object` (~"Vorgangsobjekt") does not exist anymore, since it
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -27,12 +27,14 @@ Sharing data between multiple users must be as easy as possible. Providing acces
|
||||
|
||||
### 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
|
||||
@ -40,6 +42,7 @@ As mentioned, sharing is the new way of providing access to data. In fact, we ar
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -67,8 +70,11 @@ User groups define permissions in konova. There are three main groups which a us
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user