There is no way to review which organizations a rule change recomputed #113

New Issue

2026-09-21T07:18:33Z

cgalo5758 commented

2026-09-21 07:18:33 +00:00

The question

Applying a change to an entitlement set's rules recomputes every pool (the per-organization record of what an organization is allowed) that carries the set, and writes one row per pool describing the effect. The History table's row states two counts and stops there. An earlier version unfolded the organizations inside the row with their numbers, capped at fifty names, which does not survive a change reaching hundreds of pools and cost a query per row to render. The effect rows are still written and nothing reads them. What is the review that scales?

What depends on the answer

What a History row links to; whether the effect rows are ever read back; and the per-change detail deferred along with the names: the deltas of one batch seen one at a time, the sentence a provider gives for a reduction it will enforce, and which policy governed each pool.

Options known so far

A page of its own per history row: the change's effects, paged and searchable by organization, reached from the row rather than unfolded inside it.
A panel beside the row showing the first page of effects with a link to the rest.
Nothing: the counts are the review, and the effect rows stay as evidence for whoever queries the database.

Decided when

A design states where the effects of one change are read, what a row of that review carries, and what the History row links to; the effect rows the ledger already writes are what it reads.

Migrated from status/issues.md at b7a0e15

## The question Applying a change to an entitlement set's rules recomputes every pool (the per-organization record of what an organization is allowed) that carries the set, and writes one row per pool describing the effect. The History table's row states two counts and stops there. An earlier version unfolded the organizations inside the row with their numbers, capped at fifty names, which does not survive a change reaching hundreds of pools and cost a query per row to render. The effect rows are still written and nothing reads them. What is the review that scales? ## What depends on the answer What a History row links to; whether the effect rows are ever read back; and the per-change detail deferred along with the names: the deltas of one batch seen one at a time, the sentence a provider gives for a reduction it will enforce, and which policy governed each pool. ## Options known so far - A page of its own per history row: the change's effects, paged and searchable by organization, reached from the row rather than unfolded inside it. - A panel beside the row showing the first page of effects with a link to the rest. - Nothing: the counts are the review, and the effect rows stay as evidence for whoever queries the database. ## Decided when A design states where the effects of one change are read, what a row of that review carries, and what the History row links to; the effect rows the ledger already writes are what it reads. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/entitlements area/operator-ui labels 2026-09-21 07:18:34 +00:00

cgalo5758 referenced this issue

2026-10-06 21:25:05 +00:00

A batch of rule changes has no record of its own, so its first change stands in for it #181

cgalo5758 commented

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

A rule change also has a dry run (RuleChangePreview and RuleChangeBatchPreview in internal/entitlements/rule_change.go) that sorts organizations by effect, but no page calls it. If it is wired in, previewOverlay has to take the merged rule from the commit path: it rebuilds the merge in core.commit_rule_change in Go and already differs from it, since a new quota rule with no stacking policy is additive on commit and has no policy in the preview.

A rule change also has a dry run (`RuleChangePreview` and `RuleChangeBatchPreview` in `internal/entitlements/rule_change.go`) that sorts organizations by effect, but no page calls it. If it is wired in, `previewOverlay` has to take the merged rule from the commit path: it rebuilds the merge in `core.commit_rule_change` in Go and already differs from it, since a new quota rule with no stacking policy is additive on commit and has no policy in the preview.

cgalo5758 commented

2026-10-07 07:58:47 +00:00

The dry run (RuleChangePreview, RuleChangeBatchPreview) is deleted as part of #166: nothing called it, and its rule merge had drifted from the commit's. The review-details link it was kept for runs core.commit_rule_change inside a transaction instead, reads the effect rows it wrote, and rolls back, so the review and the commit share one merge.

The dry run (`RuleChangePreview`, `RuleChangeBatchPreview`) is deleted as part of #166: nothing called it, and its rule merge had drifted from the commit's. The review-details link it was kept for runs `core.commit_rule_change` inside a transaction instead, reads the effect rows it wrote, and rolls back, so the review and the commit share one merge.

cgalo5758 referenced this issue

2026-10-16 01:56:23 +00:00

List queries can end their sort on a column two rows share, and nothing checks the last sort key #225

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#113