Add AccessGrant and CalendarAvailability ontology schemas - #1095
Add AccessGrant and CalendarAvailability ontology schemas#1095AlexTourski wants to merge 2 commits into
Conversation
📝 WalkthroughWalkthroughAdds JSON Schema contracts for ChangesAccess grant schema
Calendar availability schema
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@services/ontology/schemas/accessGrant.json`:
- Around line 241-264: Add a complementary else branch to the conditional
governing revokedAt for non-reference grants: when status is "active", constrain
revokedAt to null, while preserving the existing date-time validation for
revoked grants in the conditional around isReference and status.
- Around line 82-84: Update the delegationAllowed definition and its related
oneOf schemas, including CanonicalAccessGrant and AccessGrantReference, so the
schema accurately reflects whether delegation is supported: allow true values
through the applicable branch if delegation is intended, or remove the
authoritative required field when delegation is unavailable. Ensure no branch
simultaneously requires delegationAllowed to be false while another forbids the
key.
In `@services/ontology/schemas/calendarAvailability.json`:
- Around line 83-89: Update the calendar availability schema’s lifecycle
validation around the status and cancelledAt definitions so active records
require cancelledAt to be null. Add the corresponding else branch while
preserving the existing cancellation-timestamp requirement for non-active
states.
- Around line 15-21: Update the calendar availability record-validation layer
for the startDate and endDate fields to parse both date-time values and reject
records where endDate is less than or equal to startDate. Preserve the existing
schema property validation while enforcing that availability windows are
strictly forward-moving.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: b889e48f-59af-4d45-92c2-abe06fd34cb1
📒 Files selected for processing (2)
services/ontology/schemas/accessGrant.jsonservices/ontology/schemas/calendarAvailability.json
| "delegationAllowed": { | ||
| "type": "boolean" | ||
| }, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
delegationAllowed can never be true — the field is effectively dead.
CanonicalAccessGrant forces delegationAllowed to const: false while also requiring the key, and AccessGrantReference forbids the key entirely. Since these are the only oneOf branches, no valid AccessGrant instance can have delegationAllowed: true. If delegation support is intended, make the value configurable here; if delegation is unavailable, avoid exposing an authoritative, required field that upstream/downstream consumers might treat as controllable.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/ontology/schemas/accessGrant.json` around lines 82 - 84, Update the
delegationAllowed definition and its related oneOf schemas, including
CanonicalAccessGrant and AccessGrantReference, so the schema accurately reflects
whether delegation is supported: allow true values through the applicable branch
if delegation is intended, or remove the authoritative required field when
delegation is unavailable. Ensure no branch simultaneously requires
delegationAllowed to be false while another forbids the key.
| { | ||
| "if": { | ||
| "properties": { | ||
| "isReference": { | ||
| "const": false | ||
| }, | ||
| "status": { | ||
| "const": "revoked" | ||
| } | ||
| }, | ||
| "required": [ | ||
| "isReference", | ||
| "status" | ||
| ] | ||
| }, | ||
| "then": { | ||
| "properties": { | ||
| "revokedAt": { | ||
| "type": "string", | ||
| "format": "date-time" | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Revocation timestamp only validated one-way.
This conditional forces revokedAt to a date-time string when status == "revoked", but there's no complementary constraint forcing revokedAt to be null when status is "active". An active canonical grant could carry a stray non-null revokedAt, which is an inconsistent state.
♻️ Proposed fix: add an else branch
{
"if": {
"properties": {
"isReference": {
"const": false
},
"status": {
"const": "revoked"
}
},
"required": [
"isReference",
"status"
]
},
"then": {
"properties": {
"revokedAt": {
"type": "string",
"format": "date-time"
}
}
+ },
+ "else": {
+ "properties": {
+ "revokedAt": {
+ "type": "null"
+ }
+ }
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "if": { | |
| "properties": { | |
| "isReference": { | |
| "const": false | |
| }, | |
| "status": { | |
| "const": "revoked" | |
| } | |
| }, | |
| "required": [ | |
| "isReference", | |
| "status" | |
| ] | |
| }, | |
| "then": { | |
| "properties": { | |
| "revokedAt": { | |
| "type": "string", | |
| "format": "date-time" | |
| } | |
| } | |
| } | |
| } | |
| { | |
| "if": { | |
| "properties": { | |
| "isReference": { | |
| "const": false | |
| }, | |
| "status": { | |
| "const": "revoked" | |
| } | |
| }, | |
| "required": [ | |
| "isReference", | |
| "status" | |
| ] | |
| }, | |
| "then": { | |
| "properties": { | |
| "revokedAt": { | |
| "type": "string", | |
| "format": "date-time" | |
| } | |
| } | |
| }, | |
| "else": { | |
| "properties": { | |
| "revokedAt": { | |
| "type": "null" | |
| } | |
| } | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/ontology/schemas/accessGrant.json` around lines 241 - 264, Add a
complementary else branch to the conditional governing revokedAt for
non-reference grants: when status is "active", constrain revokedAt to null,
while preserving the existing date-time validation for revoked grants in the
conditional around isReference and status.
| "startDate": { | ||
| "type": "string", | ||
| "format": "date-time" | ||
| }, | ||
| "endDate": { | ||
| "type": "string", | ||
| "format": "date-time" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
# Locate CalendarAvailability ingestion/validation paths and confirm they reject
# records whose endDate is equal to or before startDate.
rg -n -C3 -g '*.js' -g '*.ts' \
'a92c3675-dbc8-44f6-b24e-520eeadb8864|CalendarAvailability|startDate|endDate' \
servicesRepository: MetaState-Prototype-Project/prototype
Length of output: 175
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "Repo files matching calendarAvailability:"
fd -a 'calendarAvailability\.json$|calendar.*availability|availability.*calendar' . || true
echo
echo "Schema excerpt:"
if [ -f services/ontology/schemas/calendarAvailability.json ]; then
cat -n services/ontology/schemas/calendarAvailability.json
fi
echo
echo "Broader calendar/availability references:"
rg -n -i -C2 -g '*.js' -g '*.ts' -g '*.json' 'calendarAvailability|CalendarAvailability|calendar.?availability|availability.*calendar|booking.?window|startDate|endDate' . || trueRepository: MetaState-Prototype-Project/prototype
Length of output: 14985
Reject inverted availability windows.
endDate <= startDate passes this schema because JSON Schema Draft-07 validates the properties individually but has no native keyword for comparing two date-time fields. Enforce endDate > startDate in the record-validation layer.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/ontology/schemas/calendarAvailability.json` around lines 15 - 21,
Update the calendar availability record-validation layer for the startDate and
endDate fields to parse both date-time values and reject records where endDate
is less than or equal to startDate. Preserve the existing schema property
validation while enforcing that availability windows are strictly
forward-moving.
| "cancelledAt": { | ||
| "type": [ | ||
| "string", | ||
| "null" | ||
| ], | ||
| "format": "date-time" | ||
| } |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Require cancelledAt to be null while active.
status: "active" currently accepts a cancellation timestamp. Add an else branch so lifecycle state cannot be contradictory.
Proposed fix
"then": {
"properties": {
"cancelledAt": {
"type": "string",
"format": "date-time"
}
}
+ },
+ "else": {
+ "properties": {
+ "cancelledAt": {
+ "type": "null"
+ }
+ }
}Also applies to: 152-170
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/ontology/schemas/calendarAvailability.json` around lines 83 - 89,
Update the calendar availability schema’s lifecycle validation around the status
and cancelledAt definitions so active records require cancelledAt to be null.
Add the corresponding else branch while preserving the existing
cancellation-timestamp requirement for non-active states.
Summary
Adds two proposed W3DS JSON Schema draft-07 ontologies:
AccessGrantfor canonical owner-to-grantee authorization and non-authoritative discovery references.CalendarAvailabilityfor explicit owner-defined booking windows.The schemas use newly generated UUIDv4 identifiers:
15d24c04-a4f3-4e45-a00e-0123926fbc87a92c3675-dbc8-44f6-b24e-520eeadb8864This PR is intentionally a draft. Calex will not write records using these schema IDs until W3DS maintainers approve the model and merge/register the schemas.
Motivation
Calex needs interoperable records for calendar visibility, delegated event operations, explicit availability windows, and public booking policy without introducing a local authorization database or copying authoritative calendar data outside users' eVaults.
Maintainer questions / blockers
calendar:viewBusyacceptable?if/then,const) supported by the deployed Ontology validation path?Scope
Only two new files under
services/ontology/schemas/are added. No existing schema, runtime service, workflow, or deployment configuration is changed.Summary by CodeRabbit