What the operator's grants page is for, and whether an operator should issue and manage grants from it #158

New Issue

2026-10-01T07:06:34Z

cgalo5758 commented

2026-10-01 07:06:34 +00:00

The question

The operator's Grants page (/operator/grants, in the rail) lists every grant across organizations. A search covers organization and product, and filters cover delivery: All, Live, On hold, Superseded, Inactive. It is read-only. Issuing a grant and managing one (its Valid until, its note, whether it resumes, revoking it) happen only on the organization's page. The page's rows link to the grant's organization.

The page overlaps the organization page's grants table and has none of its actions. #20's survey already asks whether it still earns a place in the rail. I think the page needs a rethink, and that an operator should perhaps be able to grant from it.

What depends on the answer

Whether the page is a place to act or only a place to find. Finding means questions across organizations, such as every evaluation ending this month, every grant on hold, or every grant a given operator issued.
If it is a place to act: whether Issue grant there starts by choosing an organization, and whether a row's Manage behaves exactly as it does on the organization page, so the two surfaces never differ.
What the page shows that the organization page cannot, and so what earns its place in the rail.

Options known so far

A finding page: keep it read-only, give it the filters and columns that cross-organization questions need (ends before a date, reason, issued by), and let every row lead to its organization.
A working page: add Issue grant with an organization picker and the same Manage the organization page has, so an operator who thinks in grants rather than in organizations never has to change pages.
Remove it from the rail and fold its useful filters into the organization list or the overview, if neither of the above earns it a place.

Decided when

The page's purpose is written down. The page carries the actions and filters that purpose needs. Where it shares an action with the organization page, both run one declaration.

## The question The operator's Grants page (`/operator/grants`, in the rail) lists every grant across organizations. A search covers organization and product, and filters cover delivery: All, Live, On hold, Superseded, Inactive. It is read-only. Issuing a grant and managing one (its Valid until, its note, whether it resumes, revoking it) happen only on the organization's page. The page's rows link to the grant's organization. The page overlaps the organization page's grants table and has none of its actions. #20's survey already asks whether it still earns a place in the rail. I think the page needs a rethink, and that an operator should perhaps be able to grant from it. ## What depends on the answer - Whether the page is a place to act or only a place to find. Finding means questions across organizations, such as every evaluation ending this month, every grant on hold, or every grant a given operator issued. - If it is a place to act: whether Issue grant there starts by choosing an organization, and whether a row's Manage behaves exactly as it does on the organization page, so the two surfaces never differ. - What the page shows that the organization page cannot, and so what earns its place in the rail. ## Options known so far - A finding page: keep it read-only, give it the filters and columns that cross-organization questions need (ends before a date, reason, issued by), and let every row lead to its organization. - A working page: add Issue grant with an organization picker and the same Manage the organization page has, so an operator who thinks in grants rather than in organizations never has to change pages. - Remove it from the rail and fold its useful filters into the organization list or the overview, if neither of the above earns it a place. ## Decided when The page's purpose is written down. The page carries the actions and filters that purpose needs. Where it shares an action with the organization page, both run one declaration.

cgalo5758 added the

kind

design

area/entitlements area/operator-ui labels 2026-10-01 07:06:34 +00:00

cgalo5758 referenced this issue

2026-10-01 08:09:31 +00:00

The product and organization pages were assembled part by part and never arranged #20

cgalo5758 commented

2026-10-01 15:39:44 +00:00

Manage on the organization page opens a card under the grant's row, with Note, Valid until and Resumes, then Save, Cancel and Revoke. Editing in the row's own cells, the way an entitlement set's rules table edits a rule, does not fit this table: with ten columns, the editor pushes the table past its box at desktop width and fills only the first column at mobile width.

The card is good enough for now, but I'm not settled on it. Whatever this issue decides about where Manage lives should revisit its layout too.

Manage on the organization page opens a card under the grant's row, with Note, Valid until and Resumes, then Save, Cancel and Revoke. Editing in the row's own cells, the way an entitlement set's rules table edits a rule, does not fit this table: with ten columns, the editor pushes the table past its box at desktop width and fills only the first column at mobile width. The card is good enough for now, but I'm not settled on it. Whatever this issue decides about where Manage lives should revisit its layout too.

cgalo5758 commented

2026-10-06 21:26:10 +00:00

The Grants page and the organization page's grants table read two copies of one query (ListGrantsWithDelivery and ListGrantsWithDeliveryPage in internal/entitlements/queries/grants.sql), and tests compare only their delivery state. #189 asks for one query. If this issue puts Manage on both pages, that query comes first, or the two can disagree on Manage, the waiting reason and whether a grant resumes.

The Grants page and the organization page's grants table read two copies of one query (`ListGrantsWithDelivery` and `ListGrantsWithDeliveryPage` in `internal/entitlements/queries/grants.sql`), and tests compare only their delivery state. #189 asks for one query. If this issue puts Manage on both pages, that query comes first, or the two can disagree on Manage, the waiting reason and whether a grant resumes.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#158