Activation of Read Permissions allows you to control who can read which information in your products.
How are different types of users affected by this change?
Setting up user groups with permissions
Setting up through responsibility roles
Other impact due to read Permissions:
Limitations of read permission control
Description
Note: Development is still ongoing for this feature. The information around the feature will be updated and supplemented continuously.
Summary
Activation of read "Permissions" provides access to an extra level in the "User groups" settings for "Planning" and operational work called "Read".
Without "read Permissions" activated, all "Users" always get to read all information on the "Department" and "Menus" they have access to (with the exception if secret nodes are used). However, with the extra Permission "Read", it's possible to limit users' ability to see information.
The function is primarily for customers who have high demands that information should only be visible to people with the right "Permissions".
Contact us for advice regarding your potential use of the function. Activation for your "Organization" is done by us at "Stratsys Developers".
Expanded Description
With the Read Permissions feature activated, no read permissions to nodes are automatically given anymore, but they are controlled and distributed in the same way as permissions to change, add, and remove information in the nodes.
It is possible to limit the read permissions to certain products, Scorecard columns, and node types on selected Departments. A user can, for example, be allowed to read information about local KPIs in their Department, but not read the global KPIs.
Another way to distribute read permissions is by assigning the user a responsibility for the node - then the user is given read permission for that specific node regardless of the User groups' settings.
Example without Read Permissions activated: The user has access to the product Business Planning at the Education Committee level and then sees nodes in all columns at this level:
Example with Read Permissions activated: Here, the user has only been given read permission for the Scorecard column "Indicators" in Business Planning at the Education Committee level. Focus areas are not shown at all since they are Text nodes, but the indicators are displayed in their column:
Read Permissions are also applied when reports (specifically report parts) are created and then affect how the report parts retrieve information from the Scorecards based on the user's permissions, but the readability of the reports themselves is still controlled by the settings for Reports:
Permissions and Licenses
The Read Permissions require no product license and can be used in all products.
Activating the Feature
Note: The Read Permissions are activated by Stratsys.
When the Read Permissions are activated in your model, certain permissions are added automatically, and many behaviors change. Read through the entire article and contact us at Stratsys for more information.
User groups
When the Read Permissions are activated, all existing User groups automatically have read permissions added. This is done to ensure a smooth transition to the new model. In User groups that apply to specific products, read permissions are only given for that particular product.
Users will then be able to see nodes to roughly the same extent as before the feature was activated, with the exception of the grosslist which are specially handled with Read Permissions activated.
Users who only have product-specific permissions will no longer be able to see nodes that belong to other products, or nodes in Scorecards that lack product tagging.
Users who are set as responsible for a node through a Responsibility role will automatically retain the permission to see the node, even if the User group is changed so that the user does not have read permission for the node via the User group.
Raports
When the Read Permissions are activated, all report parts in all existing Reports will automatically receive the "Read All" permission. This means that users will not experience any change for existing Reports. If you want to adjust existing Reports, it can be done manually.
Review the User groups
During the transition to read permissions, it is important that all user groups are thoroughly reviewed so that the existing groups do not provide unwanted permissions. It is especially important to consider administration permissions, permissions to the grosslists, and general permissions to all departments. Also, consider reviewing permissions to reports in archived versions.
Tip: To maintain as high security as possible with read permissions, it is recommended to transition fully to product-specific user groups and product-specific reports.
How are different types of users affected by this change?
Full administrators
Users who have a user group with full administrative permissions as their primary or additional permissions will be able to read all nodes, regardless of the department level the permission applies to:
The exception is any secret nodes, which are controlled by a separate function.
Thus, full administrators will not notice any change in what is visible or can be done in the system when the function is activated.
Local administrators/user administrators:
Local administrators will no longer be able to use the "Change responsible" function once read permissions are activated. This is instead referred to full administrators, as they have an easier time determining if it is an appropriate change of responsibility.
Local administrators receive read permissions based on their user group and responsibility roles.
If you do not use product-specific permissions, local administrators will still have access to all scorecards and will have the opportunity to assign permissions to departments that they themselves lack permissions to, if there are user groups that allow "Read" on "All" departments.
If your database uses product-specific permissions, local administrators can only see and assign permissions to products that they themselves have permissions to, and they will not be able to administer users who have permissions for other products than themselves.
Note: Impersonation for local administrators with the role of user administrator is limited when read permissions are activated. Local administrators may only impersonate users who have permissions to the same products and departments as themselves. Read more here: Impersonation.
Users:
Regular users/reporters/members will receive read permissions based on their user groups and responsibility roles when the function is activated.
If you do not use product-specific permissions, users will still have access to see and work in all products based on their user group & responsibility role.
If you use product-specific permissions, users will only be able to see and read information on the departments and products they have permissions for.
Setting up user groups with permissions
When read permissions are active in a database, an additional icon is displayed in the administration of user groups. The icon governs read permissions based on the user group and makes it easy to see which scorecard columns users with this permission have the ability to read. 
To access all the information for a node, that is both information in the Change window and comments, etc. in the follow-up window, read Permissions must be granted as follows
- For visible nodes: Permissions are given on both the node's top Department and the Department that the comment is written on, or a department-specific Responsibility can be given on the User's Department.
- For copied nodes: Permissions are given on the Department to which the node is copied, or a department-specific Responsibility can be given on the User's Department.
Example with visibility: For the below visible Text node, read Permissions must be given both on the top Department 'Municipal Council' and on the Department 'Social Board' for Users on the Social Board to be able to access all information for this focus area:
Example with copied node: For the following copied KPI node, it is sufficient to give read Permissions on the Social Board for Users in this Department:
Therefore, it is not enough that the node is made visible to the underlying Department in order for all information to be displayed on these Departments. Visible nodes (usually Text nodes, objectives, areas, etc.) thus behave in a different way than copied nodes (usually KPI and Activity nodes).
For visible nodes, there is therefore a special department setting, which gives the User access to all nodes in their branch of the tree:
For a User in the Social Board, this means that they can read all nodes on the green-marked Departments:
Read Permissions on a Department also grant the right to read comments written for nodes on this Department. This means that the User will be able to read comments for Text nodes written on the Municipal Council in the example above.
If this is not desirable, but you want to limit the readability of the comments to the Social Board, you can instead give Permissions to nodes using Responsibility for the node - read more about this method here.
Setting up through responsibility roles
Read Permissions can also be given through Responsibility roles. The behavior differs between visible nodes (usually Text nodes, objectives, areas, etc.) and copied nodes (usually KPI and Activity nodes).
Visible nodes
"If the User has a responsibility on a Department for a visible node (usually Text nodes), the User gets to read information about that node on all Departments, for example, the name of the node, Keyword, and Description fields.
As for the readability of comments that are written for the node, there is a difference if the responsibility is department-specific or not, that is if the Responsibility role has the following setting:
If the Responsibility role is department-specific, the User will only be able to read comments on the Department to which the responsibility is assigned
If the Responsibility role is not department-specific, the User will be able to read comments from all Departments that the node is made visible on:
Copied nodes
If the User has a department-specific Responsibility for a copied node, the User always gets access to all information about the node on that specific Department. The User does not see the node on any other Department to which the node is allocated, as long as the Responsibility role is not Consolidated (or some other Permission makes the node visible).
If the Responsibility role is Consolidated, the User gets read Permissions on all Departments to which the node has been distributed.
Default responsible
If a User is set as the default responsible on a Department, it is required that the User also has the Permission to read the node on the relevant Department to automatically be assigned responsibility when a node is created.
Reports
Note: The read Permissions function for Reports is only supported for Reports created after the read Permissions were activated.
Contact your Account Manager for questions around this.
The read Permissions control which Nodes can be selected into report parts. The limitation occurs at the Scorecard column level and Department level. A User cannot select more information than they have access to, but it is possible to further limit which information is read into the report part.
Text and table sections are not affected at all by the read Permissions.
Read Reports
Read Permissions for activated Reports are given out in the same way as usual, that is, through the report-specific section in the User groups:
This means that even if a Report contains Nodes that a User does not have read Permissions for, but the User has read Permissions for the Report itself, the User will be able to read the entire content of the Report. Therefore, no filtering of the Report will occur when the User opens the Report for reading.
This also implies that your Organization, through Reports, can make information visible to Users who lack read Permissions to certain areas.
Note: Users gain access to all information in Reports that they are permitted to read, even if they do not have read Permissions for all the information in the report through their read Permissions.
Create report parts
The read Permissions affect when report sections are created and managed.
The person creating the report section needs to have read Permissions for all nodes that are selected into the report section. The read Permissions must be distributed via planning and operational work - responsibility for nodes is not enough in this case.
When the report section's structure is created, there is an additional option, where you can control which units the information should be retrieved from:
The options are limited by the user's read permissions for planning and operational work in these permission groups. For a full administrator, all options will be displayed.
Edit report parts
When a user makes changes to an existing report section, they must have read permissions for all control model columns that the report section is built from. If the user does not have this, they will not be allowed to make changes to the report section.
Note: It is not possible to limit the information in existing reports or in copied reports, if the report being copied was created before read permissions were activated.
Other impacts due to read permissions.
Grosslists
When the function is activated, the gross lists are no longer included in the standard permissions but can only be distributed through column-specific permissions.
The reason is that the gross lists compile all measures or activities available on a unit, which means that people who have the permission to see the gross list can also see nodes that they do not have permission to see in other control models.
Note: If a user is given read access to the gross list, the user will have access to all nodes in the gross list, and can then also see all information about the nodes in all products/control models that the node is linked to. Permission to the gross list should therefore be granted with caution.
Planning Version
Permission to read nodes always applies in both the current version and the planning version. Thus, it is not possible to control so that nodes from the planning version have a different read permission.
If a user has read permission via a responsibility role in a current version, but lacks the responsibility in the planning version, the user will still have read permission in the planning version.
Keep in mind that even if a user does not access the planning version in normal cases through the permission group, that is, the planning version is not activated according to the image,
they will still be able to read nodes in the planning version if the user is given a specific link to a planning view, such as a bookmark link.
Secret node
If the node is secret, only those who are authorized through the secret node function can read the node. Note that these users are granted permission to read the node even if they lack read permission from a permission group or from a responsibility role.
Limitations of read permission control
Nodes with multiple connections
If the user has permission to read the node in one of their connections, they are also allowed to read it in the others. Thus, the user can see column-specific information in other steering model columns/steering models or products if the node has connections there.
Comments that are not department-specific
Comments that are not unit-specific are saved on the unit you are on when writing the comment. Because of this, comments that are not unit-specific are only shown to users who have permission to read periodized info on the unit where it was written.
Nodes that are both visible and copied
If a node is both made visible and copied, and a global responsibility for the node is set, the user is given access to all consolidated nodes even though they are not assigned responsibility for them. This applies when the responsibility role is not consolidated.
It is possible to grant oneself permission to read periodized information higher up in the organization.
Users who have the authority to change a node can, in some cases, grant themselves higher read access by assigning themselves responsibility in a responsibility role that is not unit-specific. This applies if the user has permission to modify the node on the main unit or if the setting 'Users have the right to update all nodes for which they are responsible.' is activated and the user is responsible for the node on any unit.
Notifications
Notifications that are created when a user has Permissions to read a node remain even if the Permissions are removed. However, the user can only see the node's name.
Gadgets
Some gadgets are by default given the same name as the node they present data for. These names are displayed even if the user lacks Permissions to read the node. Both if the gadget has been distributed to the user or if the user themselves created the gadget when they had higher Permissions at the time.
Data aggregated between different nodes
Aggregated data is displayed even if the user lacks Permissions to read the nodes that the information has been generated from.