Notes & Audit troubleshooting
Twenty-seven symptoms in five groups. If your message is not here, try the portal-wide symptom index.
Notes: getting to the screen
A message says the notes failed to load
You hold a regional director or a read-only account. The wider check lets both reach Notes, the screen applies no role check of its own, and the actual rule refuses both.
Neither role has a notes workflow today. A regional director can read the audit trail instead; a read-only account satisfies no rule anywhere in PTRS.
There is no New Note button
New Note is shown only to the five roles that reach day-to-day actions. If the list also fails to load, PTRS refused you as well.
A regional director sees the button and still cannot load the list, because the two checks disagree with each other.
Notes: using the screen
The author line on every card is blank
The identity stored against a note is your own sign-in identity. All three places that try to resolve a name from it compare that against a different kind of identifier instead, so none of them can ever match, and the author's name renders as blank.
Nothing from the screen itself. The audit trail records the same note's creation against the same sign-in identity and resolves it correctly there, so the audit trail will tell you who actually wrote it.
Searching for a colleague's name finds nothing
Search matches the content and the resolved author name, and the resolved name is always blank. Only the content is actually searchable today.
My note is not attached to the child I was looking at
Every note created from the notes screen is saved as a general, unattached record, no matter what you were looking at beforehand.
Use the Notes area on the child's own record instead. That writes a different, richer kind of note, with a typed category, a confidentiality flag and follow-up tracking. See Members.
I cannot mark a note confidential
This kind of note has no such field at all. The Members module's own note does.
Write it on the child's own record instead.
Notes I did not create are in my list
Every note in the organisation is returned to everyone who can manage members, with no owner limit and no cap on how many. Everyone sees everything, including notes created against a member or an incident elsewhere.
Use the category filter or the search box.
The edit dialog stays open after Save Changes
PTRS refused the change because you do not own the note and are not a super admin, and neither the screen nor its own save action handles that failure.
Close it. Ask the owner, or a super admin.
The removal confirmation stays open after Delete
The same underlying reason, on the removal action instead of the update.
An organisation administrator cannot edit a departed colleague's note
The rule's escape hatch names a role, "Admin," that PTRS does not actually have. The seven it does have are super admin, organisation administrator, regional director, site director, Staff, guardian and read-only. That clause admits nobody.
A super admin must make the change instead.
Someone unpinned my note
Toggling pin has no ownership check at all, unlike editing and removing. Anyone who can manage members, including Staff, can pin or unpin any note in the organisation, and the control appears on every card.
Nothing from the screen itself. This is a known, recorded gap.
"Content is required" or the note is rejected as too long
Content is required and capped at 50,000 characters; category and the attached-to type are capped at 100 each.
The audit trail
An access-denied message naming the audit trail
You hold a Staff account. The wider check lets you reach the address; the screen's own check does not include Staff, and neither does the actual rule behind it.
A message says the audit trail failed to load
You hold a read-only account. The screen's own check admits it and the actual rule does not.
A message says your account is not yet assigned to an organisation
All four audit actions refuse when the account has no organisation, because the saved record itself has no automatic organisation boundary and each action must apply its own by hand.
See how a person becomes a PTRS user.
Every row's Action says "ACTIVITY"
Every explicitly logged action is saved with the fixed word Activity in this column. The saved record has no field at all for the specific action name, so its real name survives only inside the Details sentence.
Read the Details column; the actual action is inside the sentence.
Most action badges are grey
The screen only colours four names: Insert, Update, Delete, Activity, which is exactly what PTRS itself ever writes. A development copy's own starter data uses several other names instead, and those fall through to grey.
Expected on a development copy; not something you would see in a real installation.
The Action or Entity dropdown does not have the value I want
Both filter only the 50 rows already loaded, and build their own choices from those same 50 rows. A value that is not on the current page is not even offered.
Use the search box instead, which reaches PTRS and covers the whole log, together with the date range.
A message says no entries were found, but the total is not zero
An Action or Entity selection is filtering the current page and matched nothing on it. The total in the corner still describes the whole, unfiltered log.
Set both back to All.
The User column shows a long code
Listing entries resolves this correctly, and falls back to the raw sign-in identity when no account record's sign-in reference matches it, usually an account created outside the invitation process.
Check the user list in Administration.
An action I know happened is not in the log
Three reasons, in order of likelihood.
A scheduled process did it. Nothing without a signed-in person's own request behind it is captured at all, which is every one of PTRS's twelve scheduled jobs and both of its background workers.
It was only a read. Only inserts, updates, removals and explicitly logged actions are captured.
The entry was written with no organisation at all. A record type that carries neither PTRS's usual organisation boundary nor a fallback is recorded with an empty organisation, and every audit read filters on the requester's own organisation.
I want to see what the value was before the change
The values before and after are genuinely captured, on every update and removal. Neither field is returned by any read, and no screen shows them.
Nothing from the screen itself.
The integrity check
A message names a specific entry as broken, on a development copy
The starter data any development copy is built with has no fingerprints at all, and the check computes a real fingerprint for the first entry and compares it against nothing.
Expected. A verified count of zero with a break at the very first entry is the signature of this exact situation.
A message says the chain is broken, on an installation with more than one organisation
The record is written as one continuous sequence across the whole installation, with no separation by organisation, and the check only replays one organisation's own entries. It breaks on the first entry that follows another organisation's last one.
Expected on an installation shared by more than one organisation. This is a known, recorded gap.
A message says the chain is broken, on an entry with others at the same timestamp
Every entry from one save shares an identical timestamp, and both the writing and the checking rely on that same timestamp for order. The underlying storage makes no promise about the order of entries that share one, so a group can be replayed in a different order than it was actually written in.
Check whether the named entry has others sharing its exact timestamp before treating the result as evidence of anything.
A green result, and how far it actually goes
It means no entry in your organisation's own record has been removed, inserted, reordered, or had its record type, record id, action or timestamp changed.
It says nothing about who made the request, the written description, the values before and after, or where the request came from; none of those is covered by the fingerprint. See the audit hash chain.
Settings
Settings says "System configuration coming soon"
This screen is ten lines: a heading and that one sentence. It belongs to no module, checks nothing, and reaches nothing.
Your own account settings are on your profile screen; see change your own password. Organisation and site settings live on Centers. There is no separate, whole-installation configuration screen today.
Related
Checked against PTRS on 7 September 2026.