Permission Groups
A permission group is a named bundle of permission keys. People are given groups, never individual keys — which is what keeps access reviewable as an organisation grows.
Settings ▸ Administration ▸ Permissions manages them.
The page
| Panel | Contents |
|---|---|
| Groups | Every permission group, with Filter groups… |
| Permission Keys | The keys in the selected group, with Filter permissions… |
| Inheritance | Groups this one builds on — see Inheritance |
| Users | Who has this group assigned |
The default groups
eConnect ships with a set of groups covering the common roles:
| Group | Intended for |
|---|---|
| Admin | Day-to-day administration |
| Operator | Staff working the floor |
| Viewer | Read-only access |
| SysAdmin | System configuration |
| ServiceOnly | Integrations, not people |
| SensitiveData | Access to restricted material |
These are a starting point. Most sites end up with groups matching their own roles, and that is the intended use — the defaults are not meant to be the final answer.
Creating one
Add group, name it, then add keys. Name it after the role, not the rights: "Shift Supervisor" stays meaningful as its contents change, while "Can Delete Subjects" becomes a lie the first time somebody edits it.
Use Filter permissions… to find keys rather than scrolling. The full reference is the Permission Keys page, and the v11 additions are in Permission Keys in v11.
Grant the narrowest thing that works
The single most useful habit in eConnect administration. It is quicker to give everybody Admin, and it is the reason most sites cannot answer "who can delete a subject?"
Two practical consequences:
- A person who cannot delete cannot delete by accident.
- An access review is tractable when groups are meaningful and impossible when everyone holds everything.
Start people narrow and add what they turn out to need. The complaint is easy to fix; the audit finding is not.
Editing an existing group
Changes take effect for everyone holding the group. Before adding a key to a widely-held group, consider whether a new, narrower group is a better answer.
Removing a key is the change to be careful with: it can stop somebody mid-task with an error they cannot interpret. Tell people before narrowing an existing group.
Deleting
Delete Permission Group removes it from every user who had it. Check the Users panel first — that is the list of people whose access you are about to change.
Permissions are not the same as scope
A permission says what somebody may do. A logical group says what they may see. Someone can hold every key and see nothing, because their logical group covers nothing.
Confusing the two is the commonest source of "why can this person not see anything?"
Enforced on the server
These rights are enforced on the server, not merely hidden in the interface. Every client — the desktop application, the browser, the API and the Ace — is held to the same limits.
What you see reflects what you hold
Administration screens in version 11 show only the controls your own keys allow. Somebody who may associate users with groups, but not create or delete groups, opens the Permissions screen and finds the key tree and the inheritance editor readable but read-only, with the Add, Delete and Create defaults controls absent rather than present and failing.
That is deliberate: seeing which keys a group carries is usually why such a person opens the page at all, so the page is not withheld — only the actions are. Where an entire settings page is beyond your keys, it is not rendered, whether you reach it from a tile or by address.
What is recorded
Creating, changing and deleting permission groups is audited under the permissions administration type. A point-in-time picture of who holds what is available from The Security and Access Report.