Sponsor and recipient tasks
| Identifier / actor | Meaning |
|---|---|
| Sponsor 4001 | Member who owns the sponsorship. |
| Recipient 4002 | Member who may receive a slot membership; not the sponsor. |
Pricing 2001 / subscription_id | Configured publisher Pricing under a Plan. |
| Sponsorship 8001 | Parent record linking sponsor and Pricing. |
| Slot 9001 | Invitation/recipient capacity record under that sponsorship. |
| Membership ID | User↔Plan relationship, separate from parent/slot/Pricing IDs. |
| Activation code | Slot activation credential, not a member token. |
Inspect and update as the sponsor
- List own sponsorships using sponsor 4001’s member/resource context.
- Read parent 8001 or its slot list. The parent has nested recipient slots; the separate slot list is base-only.
- Read slot 9001 with the slot ID. Do not put Pricing 2001 or parent 8001 in its path.
- If preferences need changing, update parent 8001. Payer preference and first membership renewal flags change sequentially; they are not a charge/refund or every-slot access decision.
flowchart LR
S[Sponsor member] --> P[Sponsorship record]
P --> C[Configured Pricing under Plan]
P --> L[Slots]
L --> R[Recipient identity or invitation]
P --> M[First associated membership summary]
The diagram describes record links, not an automatic purchase/activation sequence. Existing sponsorships are inputs; these operations do not create a purchase. The first membership summary can differ from individual slot membership state. Responses can omit some fields, and record saves and event attempts can fail separately. Use the documented content-access decision when serving an article.
Invite or clear as the sponsor
| Need | Operation | Decision |
|---|---|---|
| Set contact or attempt another notification | Slot invitation | Same email can repeat events; changed nonempty email regenerates code. Neither verifies recipient identity nor proves delivery. |
| Reset a multi-seat slot | Clear | Resets recipient/code and attempts first linked membership deletion/history; configured cleanup can remove user content-view records across resources. Gift type excluded. |
Invitation edits do not transfer an activated membership. Clearing is a consequential account change, not an email recall or refund. It commits before a later notification event; inspect saved slot and membership/access state after any failure before another action.
Accept an intended slot as the recipient
- List pending email-matched slots using reader@example.com’s member context. This selects parents with no stored
expired_atmarker and unactivated, code-bearing slots. It does not check actual end dates, reserve a slot or activate membership. - If accepting an intended code, activate with recipient 4002’s active member context. Code lookup does not repeat list email/parent-expiry conditions. An empty
recipient_idallows the member/code holder past the ID check without email verification; keep the code protected. - Inspect membership/account state and request content access separately. Activation attempts replacement/history/sponsorship/cache/content-view effects, not a provider charge.
- For an intended gift payer change, turn off sponsor payment. This changes a parent flag; it does not refund, expire or delete membership. An unbound recipient can yield an error after mutation.
flowchart TD
S[Sponsor sets slot email] --> Q[Attempt invitation events]
Q -->|If delivered| C[Recipient receives notified code]
L[Email-matched member lists invitations] --> K[Returned activation code]
C --> A[Active member submits intended code]
K --> A
I[Existing code supplied by issuer] --> A
A --> G[Gift membership branch]
A --> M[Multi-seat parent membership branch]
G --> W[Attempt slot activation and events]
M --> W
W --> D[Separate account and access inspection]
F[Gift recipient payer-off choice] --> P[Attempt parent payer-flag change]
A recipient can obtain a code from the email-matched invitation list or an existing issuer-supplied flow; the sponsor invitation response also exposes the stored code. Notification is another conditional route, and a queue attempt does not prove delivery. Protect the code and choose the intended recipient identity.
Activation checks code/resource and recipient ID only if bound, not contact email or parent expiry. The two branches have distinct trial/parent/end-date behavior. Account, slot and event writes are not one atomic unit. Turning off sponsor payment is a separate choice. It does not refund money, expire or delete the membership.