Keep work started before signup
Let visitors begin useful work before they create an account. When they register, Wildo can move the eligible records to their authenticated identity instead of making them start again.
Choose which resources allow anonymous ownership and whether existing work is added, replaced or discarded during conversion.
Example — Keep a draft after creating an account
A visitor writes a draft note, then registers. The same draft becomes theirs as a signed-in member, without copying it through the browser.
For engineers
Enable continuity for the destination account
Set anonymousSessionsEnabled: true in the destination user type’s authentication policy, as Wonder Todos does for its member accounts. This is checked again by transposeOwnership: a resource’s anonymous settings alone do not authorize conversion into every account type.
Opt the resource into anonymous ownership
Wonder Todos’ draft-note resource declares the policy alongside its schema and operations. Selected configuration from draft-notes.resources-config.ts:
mainSchema: DraftNotes_Schema,
resourceIdentifier: TasksManager_ResourceType.DRAFT_NOTES,
resourceFieldIdentifier: TasksManager_ResourceFieldIdentifier[TasksManager_ResourceType.DRAFT_NOTES],
resourceRelationships: resourcesRelationships,
isSystemResource: false,
isAnonymizable: true,
transpositionPolicy: ResourceTranspositionPolicy.ADD,
systemAccessPolicy: { exportSubject: ResourceSystemAccessMode.ALLOWED },
Its create/read/list/update variants admit both CORE_APP_ROLES.APP_ANONYMOUS and CORE_APP_ROLES.APP_USER. The resource must use the supported user-self ownership scope; an anonymous identity does not become organization membership.
Decide how conversion treats existing records
| Policy | Conversion behavior |
|---|---|
ADD | Reassign the anonymous records to the authenticated owner |
REPLACE | Remove the authenticated owner’s existing records for that resource before moving the anonymous records |
DISCARD | Remove the anonymous records instead of attaching them |
These are data-lifecycle choices, not display preferences. Use replacement only when that is what the application means.
Hand off the server-recognized session
The authentication controller passes the recognized anonymous identity into transposeOwnership after conversion. The server updates ownership and records the result; the browser does not prove ownership by submitting an arbitrary user identifier. Incomplete resource moves are tracked and retried by reconciliation, so conversion is not modeled as an all-or-nothing copy in frontend state.
Reconciliation deliberately does not repeat REPLACE deletion: the account may have gained new records since conversion. If the initial deletion failed, retry can leave both the account’s existing records and the moved anonymous records. This preserves subsequent work rather than deleting it to recreate the original replacement outcome.
For website-to-application continuity, configure the actual cookie and deployment topology and initialize non-essential sessions according to the application’s consent policy. The anonymous-session mechanism supplies continuity; it does not replace authentication or consent.