Profiles

The actors, sorted into categories. A profile is recognised by a condition on the identity; the permissions then say what it is allowed to do.

Users and admins

A station has two kinds of people, and two access planes that do not mix:

	users — the room	admins — the console
product station	the customers	the product builder's team
process station	the employees, team members	the admin, the IT team
do	reserve, approve, submit	configure, publish, read the log, handle incidents
governed by	profiles and permissions, in the config	the console's rights, in the organisation

The employee is to a process station what the customer is to a product station; the IT admin is what the product builder is. The same person can hold both: an IT employee who submits the creation of an account acts as a user with profile it; when they change the config, as an admin.

Profiles and permissions apply to users, and to the agents acting for them. Not to admins, nor to automations.

Profiles: the "who", as kinds are the "what"

A kind classifies actions by a condition on their fields, and can change their presentation, their selection and their submit. A profile classifies users by a condition on their identity, and can change the same points.

profiles:
  anonyme:                                                          # the default profile
    when: "identity.authenticated == false"
    grants: [cuisine.getMenu, cuisine.placeOrder, cuisine.getDeliveryOptions, cuisine.createDelivery]
  client:
    when: "identity.authenticated and identity.type == 'person'"
    grants: [cuisine.getMenu, cuisine.placeOrder, cuisine.getDeliveryOptions, cuisine.createDelivery,
             cuisine.listOrders, cuisine.cancelOrder]
  agent-entreprise:                                                 # no cancelOrder: cancelling stays a human act
    when: "identity.type == 'agent' and identity.org != null"
    grants: [cuisine.getMenu, cuisine.placeOrder, cuisine.getDeliveryOptions, cuisine.createDelivery]
  manager:
    when: "'support-manager' in identity.roles"
    grants: [paiement.proposeRefund, paiement.createRefund]

A profile receives operations with grants; an operation no profile received is called for nobody. See Permissions.

An identity can match several profiles: all of them apply.

Identity comes from the door and its providers: an anonymous visitor of the widget, a customer verified by a code or by the tenant's login, an agent with its delegated sub-identity, an employee through the organisation's directory. The fields that when reads are described in Identity.

Specialising by profile: per_profile

A profile can be served differently, on the same points as a kind:

skills:
  - name: takeDeliveryOption
    per_profile:
      agent-entreprise:                  # an agent only delivers to a registered address
        select: {guards: [{name: adresse-enregistree, require: "$item.fields.address in identity.addresses"}]}
      manager:
        present: {fields: {margin: {from: margin, type: price}}}

Displaying is not allowing

Showing more columns to a manager is interface. Hiding a tool from a profile does not forbid it: what is allowed is written as grants and tightened by a permission or guard. What a profile must not see is set by a permission in present, which Core applies before the model (Permissions).