Workflow: Transfer Ownership
Workflow: Transfer Ownership
This workflow handles changing the owner of an ObjectInstance (or any container object) through an offer / accept process, ensuring an auditable, atomic transfer.
Flow Steps
- Offer Creation – The current owner initiates a
TransferOfferfrom the UI (Ownership tab → Transfer button). Optional escrow or price terms may be added. - Offer Delivery – Backend creates a
TransferOfferrecord and sends a notification to the target user (GraphQL Subscription or email). - Acceptance – The buyer authenticates and clicks Accept; their client signs the offer (JWT) and calls
acceptTransferOffermutation. - Atomic Update (Backend)
a. Validate signatures, ensure both parties still have the required abilities via RLS.
b. Updateowner_idon the targetobject_instances(and implicitly all non-instantiated descendants).
c. InsertTransferEventaudit row (from_owner,to_owner, timestamp).
d. Commit transaction in both Supabase and Neo4j. - Notification – Push a success toast via subscription to both parties; send email confirmation.
Bulk transfers (e.g., a whole pallet) still require only one ownership update because nested items inherit ownership.
GraphQL Operations
mutation createTransferOffer(objectId, toUserId, terms)mutation acceptTransferOffer(offerId, signature)subscription transferEvents(objectId)– optional real-time feed
Data Model Impact
- Supabase –
object_instances.owner_organization_idupdated. - Neo4j –
ownerproperty updated on node. transfer_eventstable (or audit_log) records history.
Open Items / TODO
- Escrow smart-contract integration for paid transfers.
- Support for fractional ownership (see Ownership Handling §6).
- UI design for offer revisions / counter-offers.