Who can do what in Administration

38 is the full count of things PTRS can do across four separate areas: managing users, importing data, organisations and sites, and your own account.

Area	Actions	Setting
User management	10	Manage Users
Data import	12	Manage Location
Organisations and sites	9	View All Locations
Your own account	7	None at all, just being signed in

Who is admitted

Across these 38 actions, the pattern is richer than anywhere else in PTRS: some actions narrow their area's own setting, one widens it deliberately, and a whole area has no setting at all.

Pattern	Count	Where
The area's own setting is the whole answer	28	All of user management, most of data import, all of your own account
Restates the area's own setting explicitly	4	The four site-reading actions under organisations and sites
Narrows the area's setting	5	Two site-writing actions, and three account-location actions, all narrowed further
Widens deliberately, with no sign-in required at all	1	Downloading a blank import template
Widens by having no setting at every action in the area	7	The whole "your own account" area

Two things make this area's pattern the richest in the portal so far. It is the first area where something widens in two completely different ways: a genuine no-sign-in-required action, and a whole area with no setting at all. And having no setting is not the same as "administrators only": it admits every signed-in account of every role, including a guardian and a read-only account. One of those seven actions reads a record with no organisation boundary on it at all, covered below.

The third open, no-sign-in-required action in PTRS, and it earns its place

Downloading a blank import template is the third action anywhere in PTRS that needs no sign-in at all, and unlike the first two, this one is deliberate and cannot simply be tightened. The template is offered as a plain link, and a plain link carries no proof of who is asking, so requiring a sign-in would make the download fail outright.

What it actually exposes is a single header row and nothing else: the column names PTRS accepts for the six importable record types, the same names this very documentation already publishes. It touches no stored data of any kind.

The account table has no organisation boundary of its own

Every other kind of record in PTRS is automatically limited to its own organisation by one shared rule. The table holding PTRS account records is deliberately excluded from that rule, because one account can genuinely span more than one site, in a way the shared rule cannot express.

Nine of the ten user-management actions compensate by checking the organisation themselves, by hand, and reading a user's own activity checks it too before it reads anything. That is a real strength: this area knows the shared rule does not cover it, and works around that itself rather than trusting a protection that is not actually there.

One action does not: reading a single account by its own id has no organisation check and no setting on it at all. Nothing on any screen calls it today, and the ids it would need are long, unguessable values no other screen ever hands out, but the check itself is simply absent rather than passed.

The 38 actions

User management, 10 actions, all under Manage Users

Not one narrows or widens this area's own setting.

Action	What it does	Reachable by
Read the user list	A paged list for your organisation, with roles read from the sign-in service one account at a time	The user list screen
Read one user	One account with sites, roles and a created date	The user detail screen
Send an invitation	Creates the sign-in account, assigns roles, requests the password email, writes the PTRS record and site assignments	Invite User
Update a user	Updates email and display name on both sides	User detail, Edit
Deactivate a user	Disables the sign-in account, marks it inactive, removes site assignments, clears the remembered copy of their access	Deactivate User
Reactivate a user	Re-enables the sign-in account and marks it active again. Does not restore site assignments	Reactivate User
Read assignable roles	Roles at or below your own level	The role picker, the invite dialog
Assign a role	Adds one role	The Roles card
Revoke a role	Removes one role	The Roles card
Read a user's activity	Paged history for that account	User detail

Data import, 12 actions, eleven under Manage Location

Action	What it does	Reachable by
Upload a file	Stores it and creates the job	Step 2
Validate a file	Parses it, counts rows and columns, records warnings	Step 2
Read field definitions	The 64 fields the wizard can offer	Step 1
Save field matches	Replaces the job's whole set of matches	Step 3
Suggest matches	From the column headers in your file	Step 3
Read a preview	Runs 20 sample rows through your matches	Step 4
Run the import	Writes the records, then removes the uploaded file	Step 6
Revert an import	Deletes created records, partly restores merged ones	Step 6
Read a summary	Counts, plus a breakdown by record type	Step 6
Read progress	Rows processed so far	Step 6
Read import history	The last 50 jobs for your organisation	Nothing reaches it, only a finished screen that no page in PTRS ever shows
Download a template	A two-line file naming the columns. Needs no sign-in at all	Step 1, as a plain link

Organisations and sites, 9 actions, every one with its own setting

Action	Setting	Effect on the area	Reachable by
Read organisations	View All Locations	Restates	Nothing reaches it
Read one organisation	View All Locations	Restates	Nothing reaches it
Read an organisation's sites	View All Locations	Restates	34 places across the product
Read an organisation's members	View All Locations	Restates	Nothing reaches it
Create a site	Manage Location	Narrows	Nothing reaches it
Update a site	Manage Location	Narrows	Nothing reaches it
Read an organisation's users	A staff-management setting	Narrows	Nothing reaches it
Read a user's sites	A staff-management setting	Narrows	Nothing reaches it
Set a user's sites	A staff-management setting	Narrows	User detail, Location Access, Save

Two of nine have anything calling them. The staff-management setting admits exactly the same roles as Manage Users, so the one reachable write here is available to precisely the audience already on the screen that calls it.

Reading organisations always returns exactly one row, your own organisation, in every installed copy of PTRS.

Your own account, 7 actions, no setting at all

Action	What it does	Reachable by
Read your own details	The organisation, site and guardian context every screen depends on	Every page, on load
Read any account by id	Any account record, by its own id	Nothing reaches it
Read your own preferences	Theme, language, layout, notifications	Profile, Preferences
Save your own preferences	Writes all four	Profile, Preferences
Save your own profile	Display name, phone, birth date, address	Profile, Account
Change your own password	Checks the old one, sets the new one	Profile, Security
Create or update an account from a sign-in identity	Creates or updates a PTRS record from a bare sign-in identity	Nothing reaches it

Reading your own details and creating an account from a sign-in identity both run before PTRS has resolved any organisation context, so reading your own details resolves everything itself, directly, and says so plainly in its own notes. Creating an account this way has nowhere to get an organisation from and does not set one, which is exactly why an account created this way is refused everywhere else. See How a person becomes a PTRS user.

Summary

Area	Actions	With something calling them	Without
User management	10	10	0
Data import	12	11	1
Organisations and sites	9	2	7
Your own account	7	5	2
Total	38	28	10

User management is the first area in this whole portal with nothing unreachable at all, ten of ten reached from a real screen. Organisations and sites sits close to the opposite: seven complete, correctly built actions that nothing in the product asks for, including both of its writes for a site.

Requests that cannot return a correct answer

Four of the 28 reachable actions come back with something wrong, and one can fail outright.

Action	What happens
Upload a file	Fails outright when your account has no reachable site at all
Upload a file	Ignores the site you picked and uses the first of your own reachable sites instead
Read the user list with a role filter set	The total and the page count are worked out before the filter runs, so both describe the unfiltered list
Read one user	A "last signed in" value is declared and never actually filled in
Read a user's activity	One of its two matching rules can never match anything, since nothing ever writes the field it checks

The three gates, one screen at a time

Never assume the buttons you see match what PTRS will actually accept. On these screens they do not, in both directions.

Screen	Wider navigation gate	The screen's own check	PTRS's own setting	Net effect
User list	Regional director and site director also let through	Organisation administrator, super admin only	Organisation administrator, super admin	Correct. The wider two roles reach the screen and are shown a permission message
User detail	Same	Same	Same	Correct, the same way
Data import	Same	Organisation administrator, super admin only	Site director, organisation administrator, super admin	Wrong. A site director holds the setting PTRS actually checks, and the screen refuses to show it anyway
Your own profile	Not gated at all	None	None	Correct, everyone, including a guardian

What each save actually checks

Fourteen of the 38 actions have a real check behind them. There is no check at all on any account's own device anywhere in PTRS, so these are the only field rules that exist.

Action	Rule
Send an invitation	Email required, valid, up to 300 characters. First and last name required, up to 100. At least one role, and every one a role PTRS recognises
Update a user	Both ids required. When supplied, email must be valid and up to 300 characters, display name required and up to 200
Assign or revoke a role	Both ids required. Role name required, up to 50 characters
Deactivate or reactivate a user	Both ids required. The self-check ("you cannot deactivate your own account") happens separately
Upload a file	A file, at least one record type, and a recognised duplicate choice are required. Size and format are checked separately, not by this rule
Save field matches	The job id and its matches are required. Every match needs both a source and a target name. No two matches may target the same field
Create a site	Four fields required: an organisation, a name up to 200 characters, an address up to 500, and a type up to 100
Update a site	Every field is checked only if supplied. A site's state is capped at 2 characters, unusually strict compared to the rest of this area
Create or update from a sign-in identity	A sign-in reference, a valid email up to 300 characters, and a display name up to 200 are all required
Change your own password	The current password is required. The new one must be at least 8 characters and different from the old one. Anything beyond that is the sign-in service's own rule
Save your own preferences	Theme up to 50 characters, language up to 10, layout up to 5,000. None of the three is checked against a fixed list, so any value of the right length is accepted
Save your own profile	When supplied: display name required up to 200, phone up to 30, address up to 500, country, state and city up to 100, postcode up to 20, and a birth date that cannot be in the future

Creating a site accepts three fields and fills four more on its own, setting two to blank and one to zero, and copying the state from the organisation. The organisation's own state field allows far more characters than a site's state field does, so an organisation whose state value is unusually long would produce sites that later refuse to accept that same value back.

Dropdowns against what PTRS actually accepts

Choice	Where its options come from	Verdict
Add a role, on a user's own record	PTRS itself, filtered to your level	Matches exactly, cannot offer a value PTRS would refuse
Roles, on the invite dialog	The same source	Matches exactly, the same way
The role filter on the user list	A fixed list of seven	Matches PTRS's own seven exactly. Both omit the OCCL auditor role, since neither sign-in environment defines it
Create New or Merge, on the import wizard	A fixed pair	Matches exactly. The behaviour behind the first choice is the opposite of what it describes, covered on the module landing page

No choice in this whole area ever offers a value PTRS does not recognise. That is the third area in a row this portal has found clean in this specific way, after Analytics and the Parent Portal.

What is remembered, and for how long

What	How long	Cleared by
A signed-in account's organisation and site access	A few minutes	Deactivating, reactivating, or changing site access
A site list for an organisation	Longer, about a quarter hour	Creating or updating a site

Reading a site list checks its remembered copy before it checks that the organisation named even exists, so a fresh copy skips both that check and the usual organisation boundary. Reaching another organisation's site list that way needs its long, unguessable id, which nothing in this area will ever hand out, plus a copy that has not yet expired. It is recorded here because the order is wrong, not because it is something that can actually be exploited today.

---

Related

• What an import writes
• How a person becomes a PTRS user