Commit fd177e5e authored by Ewa Smula's avatar Ewa Smula
Browse files

changes as per Thu call

parent f04bc6bd
img/permissions_table.png

234 KB | W: | H:

img/permissions_table.png

309 KB | W: | H:

img/permissions_table.png
img/permissions_table.png
img/permissions_table.png
img/permissions_table.png
  • 2-up
  • Swipe
  • Onion skin
......@@ -16,7 +16,7 @@ The *Contract Management* module allows recording legal documents signed in the
![Alt](../img/add_button.png)
3. You will see an empty Contract Form. The *Project* field is optional, meanwhile, in practice most contracts are signed in the context of a research project. In the *Roles* field, you are expected to select one or more GDPR role that identifies your institutions roles as described in the Contract. The roles are: *Controller*, *Joint Controller* and *Processor* ([find out more about the GDPR roles](https://edps.europa.eu/sites/edp/files/publication/19-11-07_edps_guidelines_on_controller_processor_and_jc_reg_2018_1725_en.pdf)).
In the *Other comments* section you may describe the nature of the document or if the document has an ID/REF e.g. from a document management system, you may put it in. Just like projects and datasets, when creating contracts you are expected to provide a local responsible in the *Local Custodians* field. As stated before, one of the Local Custodians must be a user with VIP Privileges. E.g. in the demo deployment *alice.white* is a research principle investigator and is a VIP user.<br />
In the *Other comments* section you may describe the nature of the document or if the document has an ID/REF e.g. from a document management system, you may put it in. Just like projects and datasets, when creating contracts you are expected to provide a local responsible in the *Local Custodians* field. As stated before, one of the Local Custodians must be a user with VIP Privileges.<br />
......
......@@ -34,14 +34,12 @@ After initial creation the dataset will be in a skeletal form. The dataset needs
2. You will see the *Data declaration Creation Quick Form* as below. With the *Data declaration Creation Quick Form* you are asked for a *Title* for the declaration and denote where the data was *Obtained from* by selecting one of three options. For the *Title* one can use the same title you used earlier when creating the dataset. However, if you're going to have multiple declarations within a dataset you can give them names based on their source or their type (e.g. Helsinki Cohort, Parkinson Study-2, LuxPARK PARK2 Cell lines etc). It is important that the *Title* is a name that is familiar to you and your research group as it will be used in free text search over datasets. The options for the *Obtained from* field is described in detail below.
<br>
<!-- The options for the *Obtained from* field is described in detail [in the remainder of this section](#DDEC_OPTIONS). <br /> -->
<span style="display:block;text-align:center">![Alt]({{ "img/datadec_quick_form.png" | relative_url }}){:width="600px"}</span>
3. Click SUBMIT. The data declaration will be created and you will be taken to the *Data Declaration Editor Page*.
<!-- Before we describe the details of data declaration editing we will discuss the three different options for specifying the origin of data in DAISY. -->
<br>
<!-- <a name="DDEC_OPTIONS"></a> -->
<big> **Obtained from** field</big>
......@@ -160,6 +158,8 @@ As discussed above, when data of one project is being accessed in the context of
## 4.2.5 Manage Dataset Transfers
*Transfers* holds information on datasets flow between project's parties and details on datasets access by external partners. Dataset can be transferred to the external partners or they can get access to view the datasets.
<mark> To add new data transfer: </mark>
1. Click the plus button on the Transfers details box.
......@@ -180,9 +180,11 @@ As discussed above, when data of one project is being accessed in the context of
## **4.2.6 Appendix for VIP user**
NOTE: Standard user can be granted with project's administrator permission the current project's administrator.
By clicking *eye button* in the dataset overview box, VIP user can enter *Change permission* page.
The management of the dataset's access permissions is alike to project's permissions described in [** 3.2.7. appendix**]({{ "/manual/project_management_details/#327-appendix-for-vip-users**" | relative_url }}).
This section describes management of the dataset's access permissions. If VIP user (check [users groups here]({{ "manual/#what-are-the-users-groups" | relative_url }})) owns a dataset or is its Local Custodian, he can grant other users with permissions for the dataset.
<!-- This section describes management of the dataset's access permissions. If VIP user (check [users groups here]({{ "manual/#what-are-the-users-groups" | relative_url }})) owns a dataset or is its Local Custodian, he can grant other users with permissions for the dataset.
By clicking *eye button* in the dataset overview box, VIP user can enter *Change permission* page.
......@@ -200,7 +202,7 @@ By clicking *eye button* in the dataset overview box, VIP user can enter *Change
- **View**
Grant the right to view this dataset.
- **Protected**
Grant the right to access protected information on this dataset.
Grant the right to access protected information on this dataset. -->
---
......
......@@ -5,41 +5,6 @@ With the *Definitions* module, DAISY allows the management of *Contacts*, *Cohor
[**See full section Definitions Management.**]({{ "/manual/definitions_management_details" | relative_url }})
<!-- <a name="COH_M"></a> -->
<!-- ## 6.1 Cohorts Management
Cohort is a study that collects data and/or bio-samples from a group of participants (e.g. longitudinal case-control or family studies). A cohort is linked to the creation of data and is considered its ultimate source.
In order to effectively handle data subjects' requests, as per GDPR, it is crucial that an institution keeps track of what data it keeps from which cohorts. Inline with this, DAISY allows maintaining a list of *Cohorts* and link *Datasets* to *Cohorts*.
The information kept on cohorts can be seen in the associated *Editor Page* seen below. Cohorts are expected to have a *Title* unique to them, and they are linked to one or more *Cohort Owners*, which are that are Principle Investigators, Clinicians running the study. Cohorts owners are kept as *Contacts* in DAISY. In order to maintain a controlled list of cohorts, the administrator for the DAISY deployment may assign an accession number to the *Cohort*, which would be the unique identifier for this Cohort. <br />
<span style="display:block;text-align:center">![Alt]({{ "img/cohort_edit_form.png" | relative_url }}){:width="800px"}</span>
<!-- <a name="PAR_M"></a> -->
<!-- ## 6.2 Partners Management -->
<!-- A *Partner* is a research collaborator that is the source and/or recipient of human data. Partners are also legal entities with whom contracts are signed. Clinical entities that run longitudinal cohorts, research institutes, or data hubs are all examples of Partners.
In accordance, when maintaining *Dataset* source info, *Dataset* transfer info or when creating *Contract* records, you will be asked to select Partners.
The information kept on partners can be seen in the associated *Editor Page* seen below.
<br />
<span style="display:block;text-align:center">![Alt]({{ "img/partner_edit_form.png" | relative_url }}){:width="800px"}</span> -->
<!-- <a name="CONN_M"></a> -->
<!-- ## 6.3 Contacts Management
DAISY allows keeping an address book of all contact persons related to the *Projects*, *Datasets*, *Cohorts* and *Contracts*.
The information kept on contacts is pretty standard as can be seen in the associated *Editor Page* given below.
<br />
<span style="display:block;text-align:center">![Alt]({{ "img/contact_edit_form.png" | relative_url }}){:width="800px"}</span> -->
---
<div style="text-align: right"> <strong><a href="#top">Back to top</a></strong></div>
<br />
......@@ -50,7 +50,8 @@ The information kept on partners can be seen in the associated *Editor Page* see
<!-- <a name="CONN_M"></a> -->
### 6.3 Contacts Management
DAISY allows keeping an address book of all contact persons related to the *Projects*, *Datasets*, *Cohorts* and *Contracts*.
*Contacts* are people affiliated with the external partner institutions (e.g. collaborator PIs, project officers at the EU).
DAISY keeps the contact details (e.g email address, affiliations) of external collaborators related to the *Projects*, *Datasets*, *Cohorts* and *Contracts*.
Standard information is kept on contacts as can be seen in the associated *Editor Page* given below.
......
# 7 Types of Users and Permissions
<!-- # 7 Users' Types and Permissions, login details -->
This paragraph is recommended for DAISY administrators. [**Click here**]({{ "/manual/user_management_details/" | relative_url }}) to find out about DAISY end users and their privileges.
# 7 Users Groups and Permissions
This paragraph is recommended for DAISY superuser. [**Click here**]({{ "/manual/user_management_details/" | relative_url }}) to find out about DAISY end users and their privileges.
---
......
......@@ -6,14 +6,14 @@ order: -1
---
<small>
[User guide]({{ "/manual/" | relative_url }}) &raquo; [*7 Types of users and permissions (**GO BACK to main page**)*]({{ "/manual/#7-types-of-users-and-permissions" | relative_url }})
[User guide]({{ "/manual/" | relative_url }}) &raquo; [*7 Users groups and permissions (**GO BACK to main page**)*]({{ "/manual/#7-users-groups-and-permissions" | relative_url }})
</small>
---
<br>
# 7 Types of Users and Permissions
# 7 Users Groups and Permissions
{:.no_toc}
* TOC
......@@ -22,56 +22,40 @@ order: -1
---
<br>
DAISY is intended to be used mostly by three categories of end users in a biomedical research institution:
DAISY is intended to be used mostly by three categories of end users in a biomedical research institutions:
- Research staff (e.g. principle investigators, lab members)
- Legal support team
- IT and data management specialists
- IT and data management specialists
Specifically, DAISY has the following **user groups** to support record access control:
Above categories are assigned to particular DAISY **user groups**, which support the control of records access:
- **Standard**
This is the default role assigned to all users. All DAISY users can view all *Dataset*, *Project*, *Contract* and *Definitions* (*Cohorts*, *Partners*, *Contacts*). The document attachments of the records are excluded from this view permission.
- **VIP**
This role is typically given to research principle investigators. VIP users have all privileges on the records they own, meaning the records where the user has been appointed as the `Local Custodian`. They also have the right to give permissions to others on these records.
- **Legal**
This role is given to users that will be managing *Contract* records. Legal personnel will be able to create view and edit contract as well as view all other records in DAISY and manage their document attachments
- **Auditor**
This role would designed to an external person, who is given view-only temporary access to all DAISY records. This would typically happening an audit scenario.
- **Standard**
This is the default role assigned to all users. All DAISY users can view all Dataset, Project, Contract and Definitions (Cohorts, Partner, Contact). The document attachments of records are excluded from this view permission.
- **VIP**
This role is typically given to research principle investigators. VIP users have all privileges on the records they own, meaning the records where the user has been appointed as the ``Local Custodian``. They also have the right to give permissions to others on these records.
- **Legal**
This role is given to users that will be managing _Contract_ records. Legal personnel will be able to create view and edit contract as well as view all other records in DAISY and manage their document attachments
- **Auditor**
This role would designed to an external person, who is given view-only temporary access to all DAISY records. This would typically happening an audit scenario.
DAISY supports fine-grained permission management with the following categories of permissible actions.
The abilities to *View*, *Edit* and *Delete* records; to *View Document attachments of records* and to *Administer Permissions*.
<span style="display:block;text-align:center">![Alt]({{ "img/permissions_table.png" | relative_url }}){:width="900px"}<br/><small>Users permissions</small></span>
<!-- <span style="display:block;text-align:center">![Alt]({{ "img/login.png" | relative_url }}){:width="800px"}<br/><small>DAISY Login Page</small></span>
-->
<!--
Upon successful installation of DAISY, going to the web address ```https://${IP_ADDRESS_OR_NAME_OF_DEPLOYMENT_SERVER}```
should display the login page.
Inside the group a user can be assigned with a specific **role**, which specifies his project's permissions:
- Project's owner
- Local Custodian
- Regular user
<br>
<span style="display:block;text-align:center">![Alt]({{ "img/login.png" | relative_url }}){:width="800px"}<br/><small>DAISY Login Page</small></span>
Based on the authentication configuration made for your deployment, you may log in by:
* user definitions in an existing LDAP directory, e.g. institutional/uni credentials
* user definitions maintained within the DAISY database.
-->
<!-- <mark>DAISY is intended to be used mostly by three categories of end users in a Biomedical research institution</mark>; primarily Research staff e.g. principle investigators, lab members, legal support team, and IT and data management specialists. -->
The *back end user* is called *superuser* and is granted with *all* DAISY privileges - to manage the application's content and administer DAISY settings.
<br>
DAISY supports fine-grained permission management with the following categories of permissible actions.
The right to *View*, *Edit* and *Delete* records; to *View Document attachments of records* and to *Administer Permissions*.
The users permissions are summed up in the below table:
<span style="display:block;text-align:center">![Alt]({{ "img/permissions_table.png" | relative_url }}){:width="900px"}<br/><small>Users permissions</small></span>
<!-- Project permissions:
......@@ -88,11 +72,6 @@ Permissions
Grant the right to view this dataset. -->
<!-- | User Category | Administer Permissions | Delete | Edit | View | View Document Attachments |
| -------------|:-------------:|:-------------:|:-------------:|:-------------:|:-----|
| superuser | P<sub>all</sub>, D<sub>all</sub>, C<sub>all</sub>, Def<sub>all</sub> | P<sub>all</sub>, D<sub>all</sub>, C<sub>all</sub>, Def<sub>all</sub>| P<sub>all</sub>, D<sub>all</sub>, C<sub>all</sub>, Def<sub>all</sub>| P<sub>all</sub>, D<sub>all</sub>, C<sub>all</sub>, Def<sub>all</sub> | P<sub>all</sub>, D<sub>all</sub>, C<sub>all</sub>, Def<sub>all</sub>|
......
......@@ -35,7 +35,7 @@ This role is given to users that will be managing *Contract* records. Legal pers
If you are legal user we suggest to read firstly [DAISY at a Glance](#1-daisy-at-a-glance) section and then [Contract Management](#5-contract-management) section.
<br>
For more details go to section [Types of Users and Permissions]({{ "/manual/#7-types-of-users-and-permissions" | relative_url }}) (recommended for DAISY Administrator).
For more details go to section [Users Groups and Permissions]({{ "/manual/#7-users-groups-and-permissions" | relative_url }}) (recommended for DAISY superuser).
---
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment