🇬🇧 English

🇵🇹 Portugês
🇪🇸 Espanol

🇬🇧 English

🇵🇹 Portugês
🇪🇸 Espanol

Appearance

Best Practices for User Management ​

  • Facilitate understanding by displaying things that are related to each other together in the listings.
  • Facilitate search by minimizing the use of asterics - *.
  • Abstract in a helpful way the details of the other levels, in such a way that each relationship level can be understood on its own.

Groups ​

  1. Group names should be separated by spaces.

  2. Group names should be hierarchical, so that related things are ordered by proximity.

    That is, you should opt for FUNC STI and FUNC STI Admin instead of FUNC STI and FUNC Admin STI.

  3. Groups are characterized by the prefixes FUNC and ORG:

    • FUNC: used to assign profiles that provide access to resources.
    • ORG: only used to classify people within the organization. They do not assign profiles.

Roles ​

In an early period of the CoB platform there was a tendency to group many permissions together in a single role. However, as time went on, we started to create smaller roles. Despite the inevitable proliferation of roles, the latter became more easily understood and combined into different groups.

The aim is that when you look at a group, you can see what its roles allow you to do, without having to look at the details of the permissions. Here are some tips for creating roles:

  1. Role names should be separated by hyphens (-) when we want to separate sections, or spaces for everything else.

  2. Roles should be hierarchically named, according to the format <product> - <theme> - <capacity>

    The product section is necessary to understand the listing of roles in a Group.

    Examples of themes:

    • name of the RecordM settings
    • modules for UI
    • action and script for IntegrationM.
    • equips for the DeviceM.

  3. Roles should represent the ability to do things in terms of the products, not in terms of the business.

    Example: rm - Absences - read is correct, rm-gp-admin is not!

Permissions ​

When it comes to permissions, their main difference is that the name follows the scheme of Apache Shiro security framework and therefore here we handle the description.

In practice, experience tells us that the description is quite important in RecordMbased permissions dealing with definitions. This is because definition IDs are not intended by humans. All other permissions are relatively explicit. Their only shortcoming is the fact that they don't allow topic-based sorting in groups (able to group by similar topics).

  1. The description of a permission should be separated by hyphens (-) if we want to separate sections, or spaces for everything else.

  2. The description of a permission should be hierarchical, according to the format <theme> - <ability>.

    • the Name in RecordM definitions.
    • modules for UI
    • action and script for IntegrationM.
    • equips for DeviceM.

  3. Compound permissions should be avoided.

Although they appear to be work-saving, in reality they are more difficult to compose.

Example: definitions,instances:*:54,55does not allow you to reuse the expression if you want to separate the reading from the editing of data. And the fact that all permissions for a definition are listed together makes it difficult to work with it. This is because it is not possible to write a description that sorts this definition against two other definitions affected by it.