Setup new role

A role is very simply a Group with the sub-type Role.

This allows you to use all of the CGScript functions on groups, imports, export, and the many other system features there are on groups.

Minimum requirements

In order for a role to function, it must defined a minimum of two Role extensions.

• "Added" - is called AFTER a user has been added to the role
• "Removed" - is called AFTER a user has been removed from the role.

Suggested folder structure

The roles does not have a required folder structure beyond defining where the role extensions themselves are located. How the access to the resources that membership of the role itself is not actually part of the role structure, but in order to facilitate an easy way to get an overview of any role, here is a suggestion for how to setup a new product that utilizes roles to ensure the proper access to all resources.

In our example, that we will call RRR, we have the following requirements:

Requirements

• RRR is fundamentally a product that consist of a series of sub-products A, B and C where each consists of a number of resources:
  • A series of questionnaires.
  • A reporting portal for individuals.
  • A reporting portal for department leaders.
• Sales to RRR is through multiple channels
  • The owners, which we shall call SuperAdmins, may sell either to individuals, companies or resellers.
  • Companies may "sell" to their departments.
  • Resellers can sell to other companies.
  • Companies and individuals may buy access online.
  • The seller may restrict access to a limited set of sub-products.
• Administration of user (HR admins) in a reseller, company or department should be possible without having to pay for the account to do so.
• Payment is based on price per user that has access to a sub-product, so access to A may cost 10 per user and B may cost 20.

Access

Since the questionnaires in RRR ask sensitive information, access to each users answers is restricted:

• A user only has access to view their own data.
• A HR admin has access to the user, not the collected data of the user.

• A department leader has same access to the user as the HR admin, but also has access to aggregated data for the departments members.
• Sellers should have same access as HR admins to the companies they sell to.
• The seller may restrict access to a limited set of sub-products. I.e. it should be possible for a department to only be able to give their members access to A. Similarly, an individual buying access to A should only have access to A.

Folder structure

Name in parentheses means a role, otherwise it is a folder or questionnaire or other resource.

In brackets are access, if not specified default is [Inherit: true;], System access is not shown.

• Products
  • RRR [Inherit: false]
    • (SuperAdmins) [SuperAdmins: Write]
    • Companies [SuperAdmins: Full]
      • Company X
    • Role Exts [Inherit: false; SuperAdmins: Read; HR Admins (All Companies): Read]
      • Create Company [Impersonated]
      • Delete Company
    • Products
      • A
      • B
      • C
• Role Exts [SuperAdmins: Read; HR Admins (All Companies): Read]
  • Reset Password
  • Send GDPR data download
  • Anonymize user
  • Set access expiration

Under a Company there is the following structure:

• Company X [HR Admins (This company): Full]
  • (HR Admins)
  • (Leaders)
  • (Members)
  • Data [Inherit: false; Leaders: Read]
    • ...dcs...
  • Users
    • ...user...
  • Dept X ← which itself is a Company folder

Individuals are stored under a "not-so-special" company named "Individuals" in their own private Company folder.

Resellers are "not-so-special" companies that simply create new companies like others would create new departments.

Under the Products, the organization is as follows:

• A
  • (Participants) [HR Admins (For those companies that have access): Write; SuperAdmins: Write]
  • Qnaire A1
  • Qnaire A2
  • Reporting Individual [Participants: Read]
  • Reporting Leader [Leaders (For those companies that have access): Read]
  • Role Exts [HR Admins (For those companies that have access): Read; SuperAdmins: Read]
    • Reset user [Impersonated]
    • Give Access to A [Impersonated]

Script implementations

In this section we discuss what each script should return as documentation to function correctly

Create Company

RoleExtensionRoleDocumentation

• OnParent: true
• LimitToPath: "Companies"
• IncludeChildrenInPath: true
• PathIsRelative: true
• RoleRequired: false
• Parameters
  • "": Role. Required: false
  • Name: string, Required: true
  • Admin User first name: string, Required: false
  • Admin User last name: string, Required: false
  • Admin User email: string, Required: false
  • Inform Admin user: bool, Required: true

Delete Company

RoleExtensionRoleDocumentation

• OnParent: true
• LimitToPath: "Companies"
• IncludeChildrenInPath: true
• PathIsRelative: true
• RoleRequired: true
• Parameters
  • Are you sure: bool, Required: true

Reset Password

RoleExtensionUserDocumentation

• Toggleable: false
• InformsUsers: true
• PermissionRequired: 6

Send GDPR data download

RoleExtensionUserDocumentation

• Toggleable: false
• InformsUsers: true
• PermissionRequired: 2

Anonymize user

RoleExtensionUserDocumentation

• Toggleable: false
• InformsUsers: false
• PermissionRequired: 4

Set access expiration

RoleExtensionUserDocumentation

• Toggleable: false
• InformsUsers: false
• PermissionRequired: 4
• Parameters
  • When: date. Required: false

Reset user

RoleExtensionUserDocumentation

• Toggleable: false
• InformsUsers: false
• PermissionRequired: 4
• Parameters
  • When: date. Required: true

Give Access to A

RoleExtensionRoleDocumentation

• OnParent: true
• LimitToPath: "Products\RRR\Companies"
• IncludeChildrenInPath: true
• PathIsRelative: false
• Toggleable: true