Platform Authorizations And Packages - imona/tutorial GitHub Wiki

Authorization system of the ImonaCloud platform uses the terms Platform Abilities, Data Restrictions Applications, Groups and Roles.

Basically, there are 2 main types of authorizations, Platform Abilities and Data Restrictions. Platform Abilities represents the general authorizations of the platform. Data Restrictions are used to prevent user to access specific resources; applications of organizations, entities of applications and fields of entities.

A role consists of application users and can contain specific authorizations. Roles provide authorization management for users. Specific authorizations can be given to a group.

Groups can also have authorizations, but only application permissions can be given to the groups.

There are basically 4 types of resources:

1 - Platform Abilities

  • editPanel.developer: Developer ability. This ability is required to edit any application such as creating entities, fields, menu items etc.

Editing an application is only possible if the application is not downloaded from the marketplace, and both the logged in user and his organization have the editPanel.developer permission. Without editPanel.developer resource, only Lists and ListItems menus are available to the user.

  • dashboard.edit : Ability needed to edit the dashboards.
  • report.edit : Ability needed to edit the reports.
  • audit.view : Ability needed to view the audits.
  • layout.edit : Ability needed to edit the layout. Developer tools - Edit Layout option is available only if this permission is granted to the user.
  • addnewapplication.edit : Ability needed to create a new application on Atelier page. Add button is available only if this permission is granted to the user.
  • installAppFromScript : Ability needed to install a new application using an application script (an .imona file) on Your Apps page.
  • userManagement : Ability needed to add/edit/delete users. User, Groups and Roles under Manage menu is only available if this permission is granted to the user.
  • uninstallApp : Ability needed to uninstall an application. Uninstall button is available only if this permission is granted to the user.
  • uploadVideo : Ability needed to upload a user video. Video upload button is available only if this permission is granted to the user.
  • utilities : Ability needed to make utilities button available to the user.
  • manage : Ability needed to make manage button available to the user.
  • orgOptions : Ability needed to make organization options button available to the user.

Defined Platform Packages in master DB

  • Developer Package Authorizations asdf

  • Kobi Package Authorizations asdf

2 - Data Restrictions

a - Applications

Authorization levels for applications of the organizations can be managed. A user cannot use the applications which are not a given resource to at least one of his groups/roles. Application permissions can be managed under Manage - Groups and Manage - Roles tab.

Applications have 1 authorization type: visible.

  • visible : If the user has this resource, he/she can access the app.

b - Screens

Screens have 2 authorization types: visible and editable.

By default, if a user has the authorization to access an application, he also has view and edit permission to all entities of this application. This permissions can be restricted by two authorization types:

  • visible : If the user has this resource, he/she can view and edit the entity.
  • editable : If the user has this resource, he/she can't edit the entity but can view it's contents.

c - Fields

Fields have 2 authorization types: visible and editable.

By default, if a user has the authorization to access an application, he also has edit permission to all fields of all entities of this application. This permissions can be restricted by two authorization types:

  • visible : If the user has this resource, he/she can view and edit the field.
  • editable : If the user has this resource, he/she can't edit the field but can view it's contents.

List type of fields have an additional add item permission type.

  • add item : If the user has this resource, he/she can add item to list.

d - Menu Items

Menu Items have 1 permission type: visible. By default, if a user has the authorization to access an application, he also has edit permission to all menu items of this application. This permissions can be restricted by one authorization type:

  • visible : If the user has this resource, this menu item will be visible to the user.

Data Restriction Authorizations Tree Structure

For the management of data restrictions, first an app is chosen from the checkbox, then the table is filled in a tree structure with the app components that are subject to data restriction authorization operations;

  • Application: Top element of the tree
  • Screens: Sub elements of the application
  • Fields: Sub elements of the screens
  • Menu Items: Sub elements of the application

There are 3 type of checkboxes for each authorization type. Each component has the related checkboxes in horizontal extent:

  • Visible: Represents the visible authorization type.
  • Editable: Represents the editable authorization type.
  • Add Item: Represents the add item authorization type.

Simple rules apply to data restriction authorization tree:

  • If a component is not authorized, all of it's sub components are not authorized.
  • If a component is authorized, it's parent components are also authorized.
  • If a component has the editable authorization, it also has the visible authorization.
  • If a component has the add item authorization, it also has the editable authorization.

Example

asdf

  • Data Restrictions represents restricted access to specific components of the application. i.e. "Word Ignored" screen is not editable for the users of the role.
  • Platform Abilities represents the granted authorizations for the platform. i.e. Adding Applications is not allowed for the users of the role.