One source for permission codes
Defined centrally, literals banned, three places kept consistent, verified by the build.
Why
Once permission codes scatter as literals, the result is "change one place, miss three": the endpoint changed, the button did not, the front end shows a clickable button and the server refuses — and the problem only surfaces in a user's hands.
The rules
- Permission codes are defined centrally in a constants class; business code references the constants only.
- Literal permission codes are banned in code; a repository-wide scan fails the build on a hit.
- Referencing an unregistered permission-code constant fails the build and lists every reference.
- If the registered endpoint count does not match the real count, the build fails and prints the difference.
Three places, one truth
| Place | Content | On mismatch |
|---|---|---|
| Server constants class | permission-code definitions | build fails and lists references |
Database sys_permission | grantable items | consistency test prints the difference |
| Front-end visibility | whether a button shows | the front end decides nothing; it consumes the code set from the server |
How the front end uses them
After sign-in an endpoint returns the current user's permission-code set, and the front end decides button visibility from it. The front end implements no authorization logic — the real interception is always on the server.
Tip: the payoff of this discipline: adding a permission means changing one place, and the build tells you which place you missed.
Last updated 2026-10-09Edit this page →