Administration

Priya Nair, the organisation administrator who set up Claymont's site profile, is now the person a new organisation on PTRS turns to for everything else: accounts, roles, and a spreadsheet of children and staff that has to become real records.

Read this before anything else on this page

Two of the steps in setting PTRS up for a brand new organisation cannot be done through PTRS itself.

Nothing anywhere in the product creates an organisation. And nothing gives the very first administrator's account a place inside one, since the only thing that ever does that is an invitation, and sending an invitation itself requires an account that already has a working organisation. Both steps have to be done directly against the database, before anyone can sign in and use a screen at all.

The full sequence, with every step marked as working or not, is in Getting started.

What Administration is for

An organisation adopting PTRS arrives with children, staff, sites and a year of history sitting in spreadsheets, plus a group of people who each need a different amount of access to it. Two jobs follow from that: get the existing data in without retyping it, in a way that can be undone if the file was wrong, and give each person exactly the access their job needs, in a way that can be shown to an inspector later.

Who uses it

Who can do this

• Site director
• Organisation admin
• Super admin

Every admin screen is checked twice, and the two checks disagree on the import screen specifically: PTRS itself admits a site director there, and the screen's own check refuses that same account.

Four different audiences sit behind this one section of PTRS: managing user accounts is open to an organisation administrator and a super admin; running an import is meant for a site director too, though the screen itself currently refuses that role; reading site and organisation data reaches further, to a regional director and a staff account; and every signed-in account of every kind, including a guardian, can reach its own profile.

A day in the life

Priya opens Invite User for a new site director starting Monday. She fills in a name, an email and a role, and the confirmation reads "Invitation sent." What actually happened underneath is a sign-in account, a role, and a request for a password-setup email, and the third of those can fail silently: the email is sent by the sign-in service, not by PTRS, and a failure there is recorded in a place the new user's own activity screen can never show. Priya has learned to just ask the new hire directly whether the email arrived.

Later she runs a spreadsheet of forty new children through the import wizard. It asks her to pick a site, and the site she picks is never actually sent to the server: the records land on whichever site happens to come back first from the database for her account, while the confirmation screen still shows the name of the site she chose. She finds this out the way most administrators do, by checking the records afterward.

What PTRS does for you

• Creates a working login without touching the sign-in system directly: one save creates the account, assigns every role chosen, requests a password-setup message, and writes the matching PTRS record and site assignments together
• Stops anyone from granting a role above their own level, checked again on the server every time, so the choices shown on screen can never be more than what PTRS will actually accept
• Genuinely locks a deactivated account out: disables the sign-in account, marks the PTRS record inactive, removes every site assignment, and clears the remembered copy of that person's access so the change takes hold on their very next request rather than after several minutes
• Loads a spreadsheet of members, staff, programs, attendance, meals or incidents, for 41 of the 64 fields it offers on the mapping screen
• Reports honestly what an import actually did: the four result counts are added up one row at a time from what each record actually achieved, not shown from a fixed message
• Lets you undo an import: everything it created can be deleted outright, and some but not all of what it changed on an existing record can be restored
• Writes a permanent, tamper-evident record of every action taken on a user account

What stays your job

• Set up the very first organisation and its first administrator yourself, with help from whoever manages your database, since PTRS cannot do either step on its own
• Add a family's guardian and emergency contact details by hand after importing children, since an import never writes them even though the screen describing that import says it will
• Add a staff member's certifications and background check by hand after importing staff, for the same reason
• Choose which site an import's records actually land on by signing in as an account whose only assigned site is the one you want, since the site picker on the import screen itself is not read by the save behind it
• Confirm, outside PTRS, that an invited person actually received their password-setup message, since PTRS reports success whether or not that message was ever sent
• Match a person's login and their staff record yourself when both exist, since nothing in PTRS connects the two: an invited account has no staff record, and a staff record created directly or by import has no login
• Finish reviewing an import before you leave its results screen. Once you move on to another screen, undoing that import is no longer possible from any screen

What has been built

Screen	What it is	What it can do today
User list and detail	Search, filter, invite, edit roles, set site access, deactivate and reactivate	Every part of this works. The only gaps are a role filter whose count is wrong and a reactivated account that needs its sites re-added by hand
Import wizard	A six-step flow: pick record types and a site, upload a file, match up its fields, preview, choose duplicate handling, run it	Runs correctly for 41 of 64 fields. The site you pick and the duplicate choice you make are both silently ignored
Your own profile	Account details, preferences, and password	Password and account details save correctly. Preferences save and are never read back by anything

What happens on its own

Nothing on a schedule. This part of PTRS registers no recurring check of any kind.

Three things do happen automatically, in the background, without being asked for: a signed-in account's organisation and site access are remembered for a few minutes at a time, and most account changes correctly clear that; a site list is remembered for longer, and site changes correctly clear that too; and every action on a user account writes a permanent, tamper-evident record.

A role change takes a sign-out to actually apply

A role lives inside the token a person's browser already holds after signing in, not in anything PTRS re-checks on every request. Granting or removing a role updates the record immediately, and the person's current session keeps using the roles it already has until they sign out and back in.

What it connects to

Connects to	How
Centers	Sites are meant to be created from Centers' own Add Site screen. A second way to create the same kind of record exists here with no screen in front of it
Staff	An invited account gets a login and no staff record. A staff record created directly or by import gets no login. Nothing in PTRS joins the two
Members	The import wizard is one of two ways records arrive in bulk, alongside scanning a paper application
Parent Portal	An account can be created holding the guardian role, and it resolves to no guardian record, so every parent screen stays empty for that account
CACFP, Incidents, Attendance, Programs	The import wizard writes directly into all four

Not yet available

Creating an organisation

There is no screen and no save for this anywhere in the product. Only a copy of PTRS built for development, and a copy built for automated testing, can ever create one.

The duplicate-handling step of the import wizard

The choice made on this screen is never actually sent anywhere: the decision that runs was already fixed three steps earlier, at the moment the file was uploaded, to the option that skips a detected duplicate rather than creating a new record for it, regardless of what this later screen says it will do.

Choosing which site an import loads into

The site you choose on the first screen of the wizard is never actually read by the save that starts the import. The records land on whichever site happens to come first for your own account, and for an organisation administrator that can be any site in the organisation.

Import history, and reverting an import you have left

A complete history of every import, correctly limited to your own organisation, exists with a working screen built for it, including its own undo button, and no page in the product ever shows that screen. Undoing an import only works from the results screen of the wizard that just ran it.

Guardian and emergency-contact details on a member import

The member import offers a guardian's name, phone and email, and an emergency contact's name and phone, on its mapping screen, and describes itself as bringing in guardian contacts and emergency information. None of those fields is ever actually written by the save that runs the import.

Credential and background-check details on a staff import

The staff import offers CPR and first-aid certification dates and a background-check date and status, and describes itself as bringing in certifications and background checks. None of those fields is ever actually written by the save that runs the import.

The OCCL auditor role

This role is named in two settings PTRS checks internally and appears in this portal's own role picker, and it does not exist in the sign-in system at all, in either an installed copy of PTRS or a copy built for development. It cannot be granted, shown on a record, or removed, because there is nothing for PTRS to grant, show or remove.

Editing an account built into a development copy of PTRS

Every save on a user's own detail screen checks first that the stored sign-in reference actually looks like a real one, and refuses to continue if it does not, naming the reason plainly. Accounts given to a development copy of PTRS deliberately carry a placeholder reference instead of a real one, so they cannot be managed from this screen at all.

Four preferences with nowhere that reads them

Your profile's theme, language, dashboard layout and notification choice are all saved correctly, and nothing anywhere in PTRS, on any other screen, ever reads any of the four back. The notification choice is also collapsed: four separate settings are shown as one switch, and saving that one switch overwrites all four together.

Where to go next

Do a task:

• Invite a user and set their access
• Import a file of records
• Change your own password

Look something up:

• What an import writes
• Who can do what in Administration

Understand why:

• How a person becomes a PTRS user

Setting an installed copy of PTRS up for the first time: Getting started.

When something goes wrong: Administration troubleshooting.