Lesson 6 — Permissions, and archiving instead of overwriting
Identifiers are read often, written rarely, and wrong expensively. That combination is exactly what a read-only group is for, and this module ships one. It also ships a rule that matters more than the permissions do: when a number changes, the old value is archived rather than overwritten, and the history stays in the database where an auditor can see it.
The mental model: two groups here, one group there. The base module creates two security groups of its own. The HR bridge creates none at all — it leans entirely on the group that already protects this data on the core employee form.
| Group | What it lets a user do | Where it applies |
|---|---|---|
| UAE Identifiers / User | Read the catalog and look values up — read-only | Catalog and value registry |
| UAE Identifiers / Manager | Create, edit and archive registry values, and edit the catalog itself | Catalog and value registry |
Employees / Officer (hr.group_hr_user) |
See the UAE IDs group, and the Employee column on All Identifiers | Employee records |
Grant the Manager group to whoever should be able to add or correct a registry value or edit the catalog; grant the User group to anyone who should be able to look values up. On the HR side there is nothing to grant beyond what you already grant: every field the bridge touches is already restricted to Employees / Officer, the same group that already protects the Emirates ID, passport, work permit and visa fields on the core employee form. Anyone who can already see an employee's private HR details sees the UAE IDs group; anyone who cannot will not see it, or any field inside it.
The click path for a value that has changed. Open All Identifiers, find the current value for that identifier and holder, archive it, then create the new one. Do it in that order and the one-active-value rule never fights you. Both steps need the UAE Identifiers / Manager group, which is why the person who maintains these numbers should hold it and most other people should not.
Why archiving beats overwriting. A superseded identifier does not stop being interesting the moment it is replaced. It appears on invoices you have already issued, on declarations you have already filed, and in correspondence somebody will one day put in front of you. Overwrite the field and that number is gone from your database; archive it and it is still there, marked as no longer current. The constraint the module enforces is one active value — archived values do not count against it, so keeping your history costs you nothing.
Worked example. Marina Ridge Trading LLC is issued a replacement Customs Registration Number for Sharjah. The manager opens All Identifiers, archives the Sharjah value that has been superseded, and creates the new one. The Dubai registration is not touched, and both emirates' numbers remain active side by side — which is correct, and is the per-emirate rule from Lesson 4 doing its job a second time.
The failure mode. "I cannot add or edit a registry value." Reading is available to the User group; creating, editing and archiving values need the UAE Identifiers / Manager group. "I cannot see the Employee column on All Identifiers." That one is the Employees Officer access level, not a UAE Identifiers group — the two sides of this course have two different answers, and asking for the wrong group is the slowest way to get access.