Program funding & charter approval

The six Programs actions that require a second setting beyond the rest of the module, the only six in the module's 122 that do so on the money and governance side, and the only six in the whole module that exclude site directors.

The other 33 actions in this subset are on Who can do what with money and governance.

Why these six are on their own page

This portal's role picker is the only structural way it has of showing an authorization difference; a difference only stated in prose is invisible to a reader filtering the sidebar by their own role. These six actions admit a different set of roles from every other page in the module, so they get a page whose role list says so.

The precedent is Procurement analytics in CACFP and Member financial information in Members. The Programs delivery subset's single narrower action did not get one, because it narrowed to exactly the audience its page already carried. These six do not.

The settings

Setting	Roles it admits
The module-wide setting, on all 122	Site directors, regional directors, organisation administrators, super admins
The narrower financial setting, on 5	Organisation administrators, regional directors, super admins
The charter-approval setting, on 1	Organisation administrators, regional directors, super admins
Both the module-wide and either narrower setting	Organisation administrators, regional directors, super admins

A site director satisfies the module-wide setting and neither of the two narrower ones, so that role is refused by all six. It is the only role the module-wide setting admits and these six do not.

The six

Action	Setting required	Reachable by	Note
Create a funding source	the financial setting	Nothing reaches it	The only way to add a funder
Correct a funding source	the financial setting	Nothing reaches it	The only way to edit one or turn it off
Create a grant	the financial setting	Nothing reaches it	Requires an existing funding source
Correct a grant	the financial setting	Nothing reaches it	The only writer of a grant's received amount and award date
Set a grant's reporting requirements	the financial setting	Nothing reaches it	Replace-all for a grant's reporting requirements
Approve or reject a program charter	the charter-approval setting	The Charter tab	The one action here with a screen behind it

The effective audience is narrower than the setting, and differently so for each half

The setting admits organisation administrators, regional directors and super admins for all six. What a person can actually do depends on whether a screen exists and where it sits.

Charter approval, effectively organisation administrators and super admins only

Approving or rejecting a charter has a real screen behind it: the Review, Approve and Reject controls on the Charter tab.

That tab sits inside a program's own layout, and the layout loads the program's own detail before rendering any child. That check excludes regional directors, so a regional director sees a failure message and never sees the tab at all.

Gate	Admits
The charter-approval setting	organisation administrators, regional directors, super admins
The program-detail check every tab depends on	staff, site directors, organisation administrators, super admins
The module-wide setting	site directors, regional directors, organisation administrators, super admins
All three together	organisation administrators, super admins

A regional director holds the charter-approval setting and cannot use it, because the screen it lives on refuses to load for that role. The setting is not wrong; the screen it was put behind is.

The button's own gate happens to match the effective audience

The Review button only shows for organisation administrators and super admins, which is exactly the effective audience derived above.

It is worth being precise about why: the button excludes regional directors deliberately and site directors deliberately; PTRS's own check excludes site directors by setting and regional directors by the program-detail check. Two different mechanisms happen to land on the same pair. Change either one and they diverge again; nothing derives one from the other.

Elsewhere in PTRS the same construction goes the other way: the screen's own broader management grouping shows Submit for Approval to a regional director too, so that role is shown a button for an action it can never reach the screen to take.

Funding sources and grants, effectively nobody, through the interface

The five financial actions have no screen anywhere in PTRS. There is no funding sources screen, no grants screen, and no allocations panel, tab, dialog or menu entry that calls any of the five.

So their audience is organisation administrators, regional directors and super admins, by direct integration only. Through the product, no role can create a funder or a grant.

PTRS has no grant management screen at all

Ten actions, three for funding sources, five for grants, two for funding allocations, form a complete grant-management set: create a funder, record a grant against it with an amount, an award date and a grant number, attach dated reporting requirements, mark each one met, and allocate the money to programs by fiscal year.

Every one of the ten is reachable from no screen. Not one screen in the product reads or writes any of it.

Two consequences for an evaluator. First, a program's funding is invisible: the Budget tab shows a total that nothing ties to a funder. Second, the grant reporting deadlines this data model exists to hold cannot be entered, so nothing can remind anyone of them, and consistent with that, this module runs no background task of any kind.

The grant money model

The five funding actions are the module's only path to these figures. All of them are taken exactly as typed; none is worked out from anything else.

Figure	Set by	Worked out from anything?
A grant's amount	creating or correcting a grant	No, typed
A grant's amount received	correcting a grant only	No, typed. Nothing reconciles it against payments, allocations or expenses
A grant's award date	correcting a grant only	No. It is not on the create action, so a grant cannot be created as awarded with its date in one step
Whether a requirement is met	setting a grant's requirements	No, a plain yes or no in each item you send
A funding allocation's amount	creating an allocation	No, and never compared with the grant's own amount

A grant's stage has no guard at all

Both creating and correcting a grant accept any of seven stages, matched without regard to case, with no rule about which stages can follow which.

A grant can move from Closed back to Prospective, or be created Closed outright. Contrast the charter, whose two moves are both guarded, and CACFP's claim lifecycle, which checks its preconditions on every move.

Replacing a grant's requirements deletes the ones you do not resend

Setting a grant's requirements removes every existing one for that grant and saves the request's items fresh in their place. Any requirement left out of the request is destroyed, along with whether it was met and any notes on it. There is no way to add, correct or remove a single requirement on its own.

This is the same replace-all shape as setting a budget's line items and setting a program's compliance requirements. All three are the only writer for their own child records, and all three destroy anything not resent.

Charter approval, in detail

Approving or rejecting a charter is short and worth describing in full, because it is the one approval in the Programs module that does what it says.

1. Loads the charter with its approval history; refused as not found if missing.
2. Refuses any charter not currently pending.
3. Refuses any decision other than approved or rejected.
4. Writes an approval-history entry with the reviewer's email, the reviewer's identity, the decision, the comments and the exact time.
5. On approval, sets the charter to approved and records who and when. On rejection, sets it to rejected and records neither.
6. Writes an audit entry naming the charter and the reviewer.

Who approved a charter and when are written here, and nowhere else, in the whole module. Only three other actions anywhere in the solution record who approved something and when, and they all belong to CACFP.

There is no separation of duties, an organisation administrator can approve their own charter

Excluding site directors from approval is a role-level separation: the person who runs a site cannot approve that site's own charter.

It is not a person-level one. Approving does not compare the reviewer with the charter's author, and a charter does not record who wrote it. An organisation administrator can create a charter, submit it, and approve it, in three clicks, and the approval history will show their own email as the reviewer.

Compare CACFP's claim approval, which does compare the approver with the submitter and refuses when they match. That check is the only person-level separation-of-duties control found anywhere in PTRS so far, and Programs does not use it.

The reviewer's stored identity is a sign-in subject, not a link to a person's record

The identity saved on the approval history is the raw sign-in subject, not PTRS's own internal user record, so it cannot be joined back to one. The reviewer's name, which is what the screen actually shows, is taken from the sign-in account's email address instead.

The same pattern appears on document versions in this subset, and it is the shape behind the Notifications module's own undeliverable notifications.

Summary

	Count
Actions requiring a second setting	6
Requiring the financial setting	5
Requiring the charter-approval setting	1
That exclude site directors	6, all of them
That have a screen behind them	1
Reachable by a regional director in the product	0

This is now answered for all 122 Programs actions: 79 restate the module-wide setting, 13 compose the narrower membership setting, 5 compose the financial setting, 1 composes the charter-approval setting, 24 declare nothing at all, and none is open with no sign-in check. Nineteen narrow the module-wide setting; none widens it.