The "Player-scoped authentication" section of docs/authenticating.md on api/v1.0 explains that developer accounts are player accounts with higher privileges, and that Portal can grant tester, developer, or admin. It never shows what those levels actually mean.
A four-row table would fit directly under that paragraph:
| Level |
Role |
Scopes |
| player |
(none) |
|
| tester |
tester |
["accounts-read", "content-read", …] |
| developer |
developer |
["accounts-read", "accounts-write", "content-read", "content-write", …] |
| admin |
admin |
["*"] |
Level and Role are deliberately identical for the three privileged rows. The point of the column is the row where they differ: a player has no role at all. That is not a simplification for the docs — Account.scala:513 defines ROLES = Seq("tester", "developer", "admin"), and "player" is simply absent from it.
The ellipses are load-bearing too: each list is a genuine prefix of a long set, and showing alphabetical first entries makes that obvious while the read/read-write contrast between tester and developer stays visible at a glance.
The scope shapes check out against core/src/main/scala/com/disruptorbeam/clients/account/Account.scala:
ADMIN_PERMISSIONS = Set("*")TESTER_PERMISSIONS = READ_PERMISSIONS ++ PII_DATA_DUMP_PERMISSIONDEVELOPER_PERMISSIONS = READ_PERMISSIONS ++ WRITE_PERMISSIONS ++ PII_DATA_DUMP_PERMISSION
Two things to settle while writing it:
- The PII scope. Both tester and developer also carry
{service}-personalIdentifiableInformationDump for every scope. Alphabetically that sorts before -read, so a strictly alphabetical prefix would lead with it. Worth deciding whether to surface it, curate around it, or say the list is illustrative rather than sorted.
- Verify tester write access first.
LIMITED_WRITE_PERMISSIONS exists with the comment "Limited so Testers can't publish content, microservices, realms, or change accounts", but TESTER_PERMISSIONS does not include it, and the value is referenced nowhere else in the repo. Either the comment describes an intent that was dropped, or testers lost write access at some point. The table should not encode an answer until someone on the platform side confirms which.
The "Player-scoped authentication" section of
docs/authenticating.mdonapi/v1.0explains that developer accounts are player accounts with higher privileges, and that Portal can grant tester, developer, or admin. It never shows what those levels actually mean.A four-row table would fit directly under that paragraph:
tester["accounts-read", "content-read", …]developer["accounts-read", "accounts-write", "content-read", "content-write", …]admin["*"]Level and Role are deliberately identical for the three privileged rows. The point of the column is the row where they differ: a player has no role at all. That is not a simplification for the docs —
Account.scala:513definesROLES = Seq("tester", "developer", "admin"), and "player" is simply absent from it.The ellipses are load-bearing too: each list is a genuine prefix of a long set, and showing alphabetical first entries makes that obvious while the read/read-write contrast between tester and developer stays visible at a glance.
The scope shapes check out against
core/src/main/scala/com/disruptorbeam/clients/account/Account.scala:ADMIN_PERMISSIONS = Set("*")TESTER_PERMISSIONS = READ_PERMISSIONS ++ PII_DATA_DUMP_PERMISSIONDEVELOPER_PERMISSIONS = READ_PERMISSIONS ++ WRITE_PERMISSIONS ++ PII_DATA_DUMP_PERMISSIONTwo things to settle while writing it:
{service}-personalIdentifiableInformationDumpfor every scope. Alphabetically that sorts before-read, so a strictly alphabetical prefix would lead with it. Worth deciding whether to surface it, curate around it, or say the list is illustrative rather than sorted.LIMITED_WRITE_PERMISSIONSexists with the comment "Limited so Testers can't publish content, microservices, realms, or change accounts", butTESTER_PERMISSIONSdoes not include it, and the value is referenced nowhere else in the repo. Either the comment describes an intent that was dropped, or testers lost write access at some point. The table should not encode an answer until someone on the platform side confirms which.