Finding which tier an organization holds on a ladder is a loop written five times #188
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: wiki-cafe/member-console#188
Reference in New Issue
Block a user
The loop over an organization's pools and their active attachments is written four times in
internal/server/member_products.goand once ininternal/fulfillment/plan_change.go. Two copies keep the first attachment and two the last, and all walk every pool though an organization has one. The Products page reads the same provision up to five times and the same subscription three times per ladder. #148 has to change every copy.Done when: one query on the default pool returns, per ladder, the tier, its provision and source, and a subscription's period and scheduled change; nothing else loops over pools; and the page reads each row once.
The Products page, Checkout, the plan switch and its preview, the entitlements panel, the dashboard's entitlement check and fulfillment's plan changes now read an organization's position on each ladder from one query,
ListLadderPositionsByPool(internal/entitlements/queries/pool_provision_ladders.sql), on its default pool. Each provision and subscription is read once per request. The reads that still repeat are a product's prices, mapping and rules, once per ladder the product sits on.The operator side still loops over an organization's pools in
internal/server/operator_enrollment.go: the Pools panel inloadOrgEnrollmentData,IssueGrant, andsubscriptionHeldLaddersbehind the Issue grant form's warning. They move in the operator reads step of #166.