Permissions

Overview

OutDo controls access at two independent levels:

1. Workspace role — one role (Owner, Admin, Dev, User, or View) that sets the baseline of what a user can do in a workspace, or across a whole organization.
2. Permission overlay — optional fine-tuning on top of the role: which parts of the workspace a user can see (visibility) and which operations they can perform on a feature's data (add / edit / delete).

Earlier versions of OutDo attached a single role — Admin, Editor, Viewer, or Restricted — directly to each object (a workspace, a module, a feature…). That model is gone. There is no per-object role anymore: access is always workspace role + overlay.

Both levels are configured from the Admin panel's Permissions section. Reaching that section at all already requires the Admin role (or Owner, or platform superadmin) in the workspace — Dev and User accounts don't see it.

Workspace roles

The role is the baseline. It's assigned per workspace (or org-wide, inherited by every workspace of the organization that doesn't have a more specific role).

Role	What it grants
Owner	Automatic — the user who created the organization. Full access everywhere in it; not assignable through the UI. Transferable via Transferir ownership in the Funções tab.
Admin	Full control of the workspace: manage users, roles and permissions, configure everything, every data operation unrestricted. Overlays don't apply to Admin.
Dev	Configures the workspace — features, views, modules, rails — and performs every data operation, but has no access to the admin panel's user/role/permission management. Overlays don't apply to Dev.
User	Normal operator. Can add/edit/delete by default; a permission overlay can restrict specific features.
View	Read-only. Always denied write operations, regardless of any overlay.

Kiosk is a separate concept — a flag on the user account, not a workspace role. A kiosk user typically also holds a User role in the workspace it's pinned to. See Organizations & Workspaces.

Roles are assigned in the Funções tab (see below), not in Visibilidade/Operações.

Permission overlays

Overlays only affect the User role — Admin/Dev/Owner ignore them entirely, and View is always denied writes no matter what an overlay says. An overlay can only restrict a User, never grant more than the role already allows.

An overlay has two independent parts:

Part	Applies to	Controls
Visibility	Workspace, Module, Rail, View	Whether the object is shown at all (on/off toggle)
Operations	Feature	Whether add / edit / delete is allowed on that feature's records

Visibility is hierarchical: turning a Module off also hides its Rails and Views (and turning it back on doesn't restore them — you re-enable each level explicitly). Operations are per feature, independent of the visibility tree.

Each feature also carries a fourth switch, Visualizar, alongside the three operations. It is informational and not editable — it shows on automatically whenever any write operation is on, but it doesn't gate reads by itself. The actual read-gate is Visibility.

Managing permissions in the Admin panel

Open the workspace's Admin panel and go to Permissions. The sidebar lists three groups — Templates, Grupos, Utilizadores — each searchable and expandable. Click an entry to select it; the body switches from the cards view to a set of tabs for that entity.

Users get four tabs: Funções, Visibilidade, Operações, Auditoria. Templates and Groups get two: Visibilidade, Operações — you're editing the template's or group's own stored configuration instead of a specific user's.

Funções (users only)

Shows the selected user's role: one Toda a organização row (org-wide, inherited by every workspace without a more specific row) plus one row per workspace in the organization. Each row has a dropdown: Sem role, View, User, Dev, Admin. A workspace-specific choice overrides the org-wide one for that workspace only.

The organization's owner shows as a fixed Owner chip instead of a dropdown, with a Transferir ownership action for whoever can manage roles.

Visibilidade

For a Template or Group, this is a tree — Workspace → Module → Rail → View — with a toggle switch on every node. Switching a node off cascades: its children lose visibility too.

Example: to hide a module from a group, select the group in Grupos, open Visibilidade, and switch that module's toggle off. Every rail and view under it disappears with it for anyone the group applies to.

For an individual User, this tab currently shows a message instead of the tree — per-user visibility editing isn't available yet. Workspace access itself is controlled from Funções; finer visibility (module/rail/view) is configured on a Template, then pushed to the user via Aplicar (see below).

Operações

A searchable list of the workspace's features. Each row has four switches — Adicionar, Editar, Apagar, Visualizar. The first three match add/edit/delete; Visualizar is a read-only indicator (not editable) that shows on automatically whenever any write operation is on — see above. Column headers carry a switch that bulk-applies to every visible feature at once (except Visualizar, which is likewise indicator-only).

This tab works the same way for Users, Templates, and Groups — for a user it edits that user's own overlay directly; for a template/group it edits the reusable config.

Example: to remove delete access to one feature for one user, select the user, open Operações, search for the feature, and switch Apagar off. The other operations stay as they were.

Auditoria (users only)

A workspace-scoped log of role changes for the organization: grants, revocations, and changes, each with who made the change, when, and (for org-wide rows) an org-wide badge. Paginated — Carregar mais loads older entries.

Permission templates

A Permission Template bundles a role with an overlay so you can apply both together instead of configuring a user from scratch. Four built-ins ship with every organization:

Template	Role	What it's for
Admin	Admin	Workspace manager — everything unrestricted.
Dev	Dev	Configures features/views/modules/rails, full data access, no user/role/permission management.
Member	User	Normal operator, add/edit/delete allowed by default; restrict specific features afterwards via Operações.
Viewer	View	Read-only — auditors, stakeholders.

Built-in templates ship with an empty overlay (role only). Create a custom template from Adicionar template: start blank or pick one of the built-ins from the Predefinição dropdown to prefill its role and overlay, then rename and adjust. Once saved, a custom template's Visibilidade and Operações tabs behave like a group's, not like a user's: Visibilidade shows the real tree (only Templates and Groups get it — Users get the placeholder described above), while Operações reuses the same per-feature switches for all three entity types.

Use Aplicar to mass-apply a template to users — it's the hover action on the template's card in the Templates grid (tooltip "Aplicar a utilizadores"), not a context-menu item. Pick a scope — a specific workspace or org-wide — and select one or more organization members. Applying is idempotent — re-applying to a user who already matches the template's role and overlay is a no-op.

Permission groups

A Permission Group is a named configuration linked to one template — useful for keeping a labeled, editable copy of a permission profile (e.g. "Sales Team", tweaked from the Member template). Like templates, a group's Visibilidade and Operações tabs edit its own stored config directly, with the real visibility tree.

Groups have no Aplicar action and no member list — there's no way to assign a group to a set of users directly. A group is a saved, labeled config only. To actually grant its settings to users, apply the template it's linked to (or a template you've adjusted to match) via that template's Aplicar action.

Tips

• Overlays never grant more than the role already allows — if a User doesn't see an operation switch turned on where you expect, check the role first (Dev/Admin/Owner bypass overlays; View is always denied writes).
• To change what a group of people can access at once, edit a Template and use Aplicar rather than repeating the same change per user.
• Visibility toggles cascade downward when you turn them off, but not back on — re-enabling a module doesn't restore rails/views you'd previously hidden individually.
• For an individual user, edit visibility on the template you're going to apply to them, not on the user directly — the per-user tree isn't available yet.