How Can We Help?
Reporting rolesReporting roles
We're currently reworking the roles in the reporting module, and I would like to use this opportunity to explain how we envision roles should work in the reporting module. This description is only valid for the reporting module and does not pertain to the classic reporting module.
Vision
The vision is to make it clearer who can do reporting and on what.
To make this happen, any user who should be able to do reporting, must have a reporting role, either organizational (local) or global, or be an administrator. A user can only report on what they are able to read. This means that any user must have a role specific to the content type they wish to report on, or the general reporter role.
Another important distinction for reporting is how organizational roles are interpreted. For reporting, organizational roles are taken from the associated organizations, where elsewhere in Pure, it is the managing organization that determines the level of access. We need to make this distinction to make sure that users can in fact do reporting on the content that they have been involved in. Either as a researcher, or as someone who needs to get an overview of the activity their part of the organization have been involved in.
Type | Description |
---|---|
Global | Global roles can report on all the content of the content type they have a global reporting role for, regardless of the organizational units associated to the content |
Local | Local roles, can only report on the content of the assigned content type, that is associated to the content, i.e. not the managing organization, but all organizational units that are associated to the content. |
Example
To put this into context, consider the following example:
In this example, there are two organizational units assigned to the output, Faculty of Health Science and Department of Computer Science. The managing organization on this is Faculty of Health Science. To edit this output, a user must have edit right on the Faculty of Health Science. For reporting, you would be able to report on this output, if you have a reporting role on either organizations.
Values and filters
What can you then report on? If you have reporting rights on a content type, for instance research outputs, you will be able to report on all the values and use all the filters that the reporting module have. You will also be able to make relations to other content, but only to the content directly linked to the content where you have reporting rights. If you make a relation to another content type, for instance from research outputs, to persons, then you will not be able to see any other values than the short render. You will also not be able to make any further links, or use any filters on this content type.
Example
Take the research output from before.
User | Roles |
---|---|
Alice | Research output reporter, for Faculty of Health Science |
Bob | Research output reporter, for Department of Computer Science |
Charlie | Research output reporter, for Department of Politics |
Alice and Bob will be able to report on the research output above, where Charlie cannot, but all research outputs where Department of Politics are affiliated instead.
A (Research output) | B (Person) | C (Organization) |
---|---|---|
Lorem Ipsum | Nicolaj Lock | Department of Computer Science |
Lorem Ipsum | Malene Knudsen | Faculty of Health Science |
Column A is the title of the output. Column B is the name of the associated Person, and column C is the name of the organization of the person. So A is research output content type. B is a person content type, and C is an organization content type.
Since Alice only have a reporting role on research outputs, she can see all information about the research outputs for Faculty of Health Science. She can make relations to content that is related to the research output, for instance the person. For the person content type, she can only use values that are used for the short render, such as name. She cannot make any further relations from Person.
Overview
Permission | Description | Notes |
---|---|---|
Reporting | Full access to all values that can be used in the reporting module, all semantic relations are available, the type of semantic relation depends on the permission on the related content | |
Read | Only access to a limited set of values, no semantic relations are available | No filters will be available |
None | No access, cannot see content | |
Admin | Administrators, should be treated like users with reporting rights, i.e. they can report on all content, even if they don't have a specific reporting role. |
We are going to create roles for all content types, such that you have the ability to decide who should be able to do reporting on what. Right now we have global reporting roles for all content types, we are going to introduce local reporting roles for all content types as well. In addition to this, we're also contemplating adding a local role that allows for reporting on all content types.
Confidential content
For confidential content, we are introducing a new role that can be assigned to reports. This role will enable them to report on confidential content. As an example, Alice is assigned the Research output reporter role, as well as the confidential reporter role. This will enable her to report on research outputs belonging to her part of the hierarchy, including any confidential research outputs within this part of the hierarchy. Bob on the other hand has the Research output reporter role only. He can only report on non-confidential research outputs belonging to his part of the hierarchy. The same is the case for global reporters. They cannot report on confidential content, either, unless they get assigned the new confidential content reporter role.
Detailed Example
Example report
- Research output
- Organizations (associated)
- Persons (contributors) – expanded
- Organizations (affiliations)
As. seen by an administrator:
Output | Organization associated |
Person contributors |
Organization affiliations |
||||||
---|---|---|---|---|---|---|---|---|---|
Reportable | Title | Reportable | Name | Reportable | Name | ORCID* | Reportable | Name | Number of descendants* |
True | output1 | True | org1, org2 | True | person1 | orcid1 | True | org1, org2 | 10 |
True | output1 | True | org1, org2 | True | person2 | orcid2 | True | org2 | 4 |
True | output2 | True | org2 | True | person3 | orcid3 | True | org2 | 4 |
Columns with * are non-reportable details.
As seen by a user with local Output and Person reporter permissions on org1:
Output | Organization associated |
Person contributors |
Organization affiliations |
||||||
---|---|---|---|---|---|---|---|---|---|
Reportable | Title | Reportable | Name | Reportable | Name | ORCID* | Reportable | Name | Number of descendants* |
True | output1 | False | org1, org2 | True | person1 | orcid1 | False | org1, org2 | |
True | output1 | False | org1, org2 | False | person2 |
Explanation:
- output2 is not reportable by the user and the row is eliminated
- The associated organization's semantic relationship is not restricted, and the wide preview of organization name is visible because name is a reportable property.
- Person1 is affiliated with org1 and is thus reportable by the user, allowing the display of ORCID and following the affiliations semantic relationship to organizations.
- Person2 is not affiliated with org1 and is thus not reportable by the user. Hence, the non-reportable ORCID is hidden. Also, the organization affiliations relationship is restricted.
- The non-reportable Number of descendants is not visible for any rows because the user has no reporting permissions on Organization
Updated at September 26, 2024