Page Comparison

...

<version>/<domain>/<action>/[modifiers]+For instance named

Example: A pkgsecupremission instance is defined with following with properties:

• name: “Update owned offline“

...

• permission: v1/objectdata/update/$offline/$selfowner

...

Such permission grants to update instances in an offline status (status is not online and not archived) that he the operating user owns (object.owner == surfer.id)

Patterns

• version: The only available version for patterns is v1 but introducing a version in patterns will ease further improvements and ease ascendent compatibility. Until new versions are available, just keep in mind that natively handled permissions start with “v1”.

• domain: The domain of the security rule that this permission will act on. As of

  Status
  title 2021.3.0

  , objectdataand boards are handled.
  Since

  Status
  title 2022.3

  , objectactions and applications domain are handled

• action: The action within the domain that this permission will act on. As of

  Status
  title 2021.3.0

  , all actions from objectdata domain can be handled.
  modifiers: Modifiers will define the Since

  Status
  title 2022.3

  , new actions added to objectdata and objectactions are handled.

• modifiers: Modifiers will define the context for which the action will be granted. Modifiers vary from one action to the other:

  • objectdata

    • insert action: 1 modifier is to be defined: creationMode. Therefore, all insert permissions follow this pattern: v1/objectdata/insert/<creationMode>

    • changestatus action: 3 modifiers are to be defined: workflowAction, instanceStatus, ownership. Therefore, all changestatus permissions follow this pattern: v1/objectdata/changestatus/<workflowAction>/<instanceStatus>/<ownership>

    • other objectdata actions (delete, i18nfieldstranslate, order, retrievecaption, update, view): 2 modifiers are to be defined: instanceStatus, ownership. Therefore, all those actions follow this pattern: v1/objectdata/<action>/<instanceStatus>/<ownership>

  • boards

    • makepublicboard action: No modifiers - permission is granted or not

    • shareboard action: 3 modifiers are to be defined: boardVisibility, boardType, ownership,

  • applications (since

    Status
    title 2022.3

    )

    • isavailable action: 1 modifier is to be defined: applicationName. Therefore, all isavailable permissions follow this pattern: v1/applications/isavailable/<applicationName>

Modifiers

Each modifier supports specific keywords to finely define the context.

...

Ownership allows to limit a permission to the owner property of an instance. 2 7 keywords are available

• $selfowner: User must be the owner of the instance to be able to perform an action

• $anyowner: No restriction on ownership

• $boardcollaborator: Specific to boards domain - Identify the surfer as a collaborator on a board

...

• $teammember:

  Status
  colour Purple title since 2024.1

  Allows to check whether the surfer is part of the field team (team is a child multi on user). This requires the structure to have the pkg/security/collaborative config tag

• $teamleader:

  Status
  colour Purple title since 2024.1

  Allows to check whether the surfer is denoted in the field jobowner. This requires the structure to have the pkg/security/collaborative config tag

• $teamviewer:

  Status
  colour Purple title since 2024.4

  Allows to check whether the surfer is part of the field viewers (viewers is a child multi on user). This requires the structure to have the pkg/security/collaborative config tag.
  Caution, $teamviewer ownership can only be used with view action

• $public:

  Status
  colour Purple title since 2024.4

  Allows to check whether the instance is NOT private →private field as a child activated = 2. This requires the structure to have the pkg/security/collaborative config tag.

Groups pkgsecugroup

Groups allow to centralize multiple permissions on one or many objects, for one or many roles and one or many users.

...

It is possible to automatically extend some bases with the ones provided by the plugin:

1. Set plugin parameter extend_bases to true

2. Make sure extended_bases references to the coma-separated list of bases you want the plugin to extend (base_list,base_search by default)

3. Make sure extend_with references the coma-separated list of bases you want to use to extend the extended_bases list of bases (base_pkgsecurity_view by default)

By doing so, you will be instructing the plugin to extend base_list and base_search with base_pkgsecurity_view for each object.

...

Preventing bases for Developers to be extended

Given that

1. extend_bases = true

2. extended_bases = base_list,base_search

3. extend_with = base_pkgsecurity_view

To deactivate the extension for all objects for role 4 (and therefor to be able to see any instance), you can define the config to:

...

@pkgV1ObjectActions is defined to check for an objectname if some permissions were given to a user for the corresponding objectdata action → No additional configuration is required on objectactions: an action from objectactions domain will be granted if some permissions were given on objectdata

Equivalences

Cheat sheet

Find for each managed domain / action, the permission pattern

Find available values for modifiers

Find available values for modifiers

Further reading

Rights and roles To learn how the default application is configured in terms of roles and permissions

Roles & Permissions To learn how you can use a dedicated user interface to configure roles and permissions