Accepting Share Records (records/accept)

[leogdion]

[leogdion]

Gap analysis (CloudKit JS / Web Services vs openapi.yaml)

A coverage review of openapi.yaml against Apple's CloudKit JS (CloudKit.Database.acceptShares, cloudkitjs.md:804-806) and the Web Services "Sharing Records" reference (webservices.md:1610-1672) confirms this endpoint is entirely unimplemented — there is no records/accept path and no share data model anywhere in the spec (grep -i "share|participant|shortGUID" → none).

What needs to be done

1. New endpoint — acceptShares equivalent: accept a share identified by a shortGUID on behalf of the current (web-auth) user. Add the path + operationId + request/response bodies.

2. New schemas:

• Share — the cloudKit.share record model (shortGUID, forRecord/root record, publicPermission, participants, owner, currentUserParticipant).
• ShareParticipant — permission, acceptanceStatus, type (see CloudKit.ShareParticipant, cloudkitjs.md:4632-4652).

3. Share-creation keys on the modify request / RecordOperation (openapi.yaml:114-123, 1215-1225): createShortGUID on the record, and for cloudKit.share records forRecord / publicPermission / participants (webservices.md:1612-1658).

4. Share response fields on RecordResponse (openapi.yaml ~1019-1043): shortGUID, share, publicPermission, participants, owner, currentUserParticipant (webservices.md:1660-1672).

Related

• Fetching Record Information (records/resolve) #41 (Fetching Record Information / records/resolve) depends on the same Share schema groundwork.
• Reminder: do not hand-edit Sources/MistKitOpenAPI/ — change openapi.yaml and regenerate via ./Scripts/generate-openapi.sh.