Wrapgroups and workgroups

Roles-based permissions to access Wraps are set per Wrapgroup. A Wrapgroup can belong to a Workgroup, making the Wraps in the Wrapgroup available only to the Workgroup that owns it.

To simplify administration, you define groups of Wraps that belong together. The permissions for a Wrapgroup apply to all Wraps, instances, and reports in the group.

The Wraps in each Wrapgroup can be made accessible only for users in one Workgroup. You can assign separate permissions for each Role.

  • The properties of Wrapgroups are set using the Edit link on the Administration dashboard > ExcelWraps > Wrap Groups page.
  • Wraps are assigned to Wrapgroups using the Edit link on the Administration dashboard > ExcelWraps page.
  • The properties of Workgroups are set using the Edit link on the Administration dashboard > Users > Workgroups page.
  • Users are assigned to a Workgroup using the Edit link on the Administration dashboard > Users page.

The screenshot below is from the definition of a Wrapgroup. The Wrapgroup belongs to a Workgroup called “CRE”. The rules below set the permissions for the users of the CRE Workgroup, when using the Wraps in this Wrapgroup.

The lower row sets the role’s permissions for instances that the user has created, and thus own. This makes it possible for employees to have private access to their own sensitive information. The upper row sets the role’s permissions for all other instances.

If one or more roles isn’t visible here, you may need to check your settings. When you assign permissions for Wrapgroups, the visibility of Roles is controlled by Settings > ExcelWraps > Displayed Roles. The roles that are assignable are globally controlled by Settings > ExcelWraps > Assignable Roles Pool, and you select the assignable roles per Workgroup in Users > Workgroups > Assignable Roles.

Screenshot of the access control settings for wrapgroups

Trusted workgroups

On the Workgroup page, you can permanently trust one or more other Workgroups. All content belonging to a Workgroup is also accessible to its trusted Workgroups. As an example, it is likely that all subcontractor workgroups will trust the main contractor organization.

Workgroup trust is one-way, so trusting a Workgroup does not give you access to its resources.

Workgroup trust is not inherited. If an Administration workgroup trusts a Depot workgroup and the Depot workgroup trusts a Contractor workgroup, users in the Contractor workgroup do not have access to the Administration workgroup unless this trust is granted separately.

Trust a Wrap instance to a foreign workgroup

Users in a foreign workgroup may need access to a single wrap instance owned by another workgroup, e.g. when an external contractor is used to perform some work. Authorized users in the owning workgroup can then trust the contractor’s workgroup to temporarily access individual instances using the WorkgroupSelector widget.

Workgroup trust is not reciprocal. Trusting one or more wrap instances to a foreign workgroup does not provide any access to resources owned by that workgroup.

Workgroup trust is not transitive. Trusting wrap instances to a foreign workgroup does not make them available to users of any other workgroups, even if they are trusted by the foreign workgroup.

Evaluating permission

When you attempt to view a Wrap, the following rules are evaluated:

  • Are you Authenticated via login?
  • Does your Workgroup have access to the Wrap instance?
    • The Wrap can be in at least one Wrapgroup that is available to all Workgroups.
    • The Wrap can be in at least one Wrapgroup that belongs to your Workgroup.
    • The Wrap can be in at least one Wrapgroup that belongs to a Workgroup that trusts your Workgroup.
    • The Wrap instance that you want to view may be trusted to your Workgroup on the instance level.
  • Do you have a Role that has View permission in any of these Wrapgroups? The Wrap must be in at least one Wrapgroup that you can access, where at least one of your Roles is granted View permission for the Wrapgroup.

Hiding or locking tabs by user role

The permissions model described above allows you to grant permissions to user roles to view, edit, create, and delete wrap instances.

You can also lock or hide certain tabs in a Wrap depending on the user’s roles.

Lock tabs if the user has no qualifying role

On the Sheets tab, you can lock a sheet to display it in a read-only state if the user doesn’t have a role that qualifies for editing.

Screenshot of the Lock Sheet option on the Sheets tab in the task pane

Hide tabs if the user has no qualifying role

Another alternative is to hide certain tabs in the Wrap for certain roles, using settings on the Sheets tab in the WrapCreator task pane.

Screenshot of the Hide Sheet option on the Sheets tab in the task pane