Stage 7 · L29

Combine role permissions with record ownership

Core · original Session 7

Native checkpoint 07

Use the starter for this stage's focused examples. The cumulative transfer and solution belong at the stage-end capstone. Baseline checks pass; transfer checks initially fail. Downloads contain the matching native starter and solution for this stage.

Write a permission matrix before coding guards. In this revision customers and operators reserve/read their own rentals; admins read all. Operators/admins may check in. Only admins change the catalogue or create customer profiles through the administrative resource. The current public website and v1 API files are unchanged; this is an explicit local teaching policy.

Role-based permission selects actions. Attribute-based rules select the record scope and conditions: rental.owner_id must match the actor for ordinary reads, while maintenance/capacity still restrict reservation even for an admin. Administrator status does not bypass the rental state machine, stored constraints or stock rules.

Registration never accepts a role. The current role is loaded from PostgreSQL on every authenticated request. A trusted fixture creates admin/operator identities directly for tests; that is test setup, not a public role-assignment endpoint. There is no API allowing a caller to promote themselves.

The source Session07 models pending/viewer/operator/admin and hub assignments in a logistics example. Those exact roles and hub attributes are not silently mapped into Equipment. Here inactive is an authentication condition, and ownership/stock are the relevant attributes. State the mapping and the omitted hub model rather than claiming the source's full domain was installed.

Customer: reserve/read own; Operator: reserve/read own + check-in; Admin: all reads + catalogue writes; Everyone: stock/state rules still apply

Follow the running code

Focused lesson example; see the end-of-stage capstone for the cumulative app · stage 07

customer/operator: reserve and read own rentals
operator/admin: check in
admin: broader read; catalogue/customer writes
Every role: stock/state/constraints still apply
Registration: no caller-selected role.

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided lab

Read the explanation and predict the focused example’s outcome.
For each role, decide read-other, check-in and catalogue-write. Explain how local walkthrough actors are assigned without a public promotion endpoint.
Compare the observed outcome with the focused answer and state its boundary.

From the extracted stage starter root, after completing its README setup:

python run_checks.py --stage 07 --role starter --walkthrough authorization

Expected: Customers cannot read another owner's rental, check in or write catalogue. Operators read their own records and may check in. Admins have the explicit wider read and write grants. Actor setup directly updates only newly created synthetic walkthrough users in its guarded local database; registration still rejects a role field.

A role from request JSON or a stale token cannot be authoritative; role permission does not override business invariants.

Focused exercise and answer

Complete this focused exercise before reading its answer. The full native transfer is introduced only at the end of the stage.

Your transfer task: For each role, decide read-other, check-in and catalogue-write. Explain how local walkthrough actors are assigned without a public promotion endpoint.

For each role, decide read-other, check-in and catalogue-write. Explain how local walkthrough actors are assigned without a public promotion endpoint.

Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

Customers cannot read another owner's rental, check in or write catalogue. Operators read their own records and may check in. Admins have the explicit wider read and write grants. Actor setup directly updates only newly created synthetic walkthrough users in its guarded local database; registration still rejects a role field.

Check your reasoning

Which attributes determine an ordinary rental read?

Show the explanation

Current actor identity/role and the rental's stored owner, applied before the query returns data.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.