GSoC 2026: Expose missing JSON Schema keys (readOnly + format) in @types payload

Google Summer of Code
1
  1. What I verified (with evidence)
  • GET /Plone/@types/<type> currently returns JSON Schema-like data: properties, required, enum, enumNames, uniqueItems, etc.
  • In my local backend, Document and Event only showed required + enum/enumNames (and uniqueItems in arrays).
  1. What I found in plone.restapi code
  • @types endpoint served by TypesGet (services/types/get.py) → get_jsonschema_for_fti() (types/utils.py) → get_jsonschema_properties() using IJsonSchemaProvider adapters per field.
  • Base serializer is DefaultJsonSchemaProvider.get_schema() and subclasses override additional().
  1. Gap: missing standard JSON Schema keys
  • readOnly: available as field.readonly for all zope.schema fields, but not emitted.
  • format: can be derived safely for specific field types (Email, URI, Date, Datetime), but not emitted.
    These are standard JSON Schema annotations; would be additive and backward-compatible.
  1. Proposal (minimal + safe)
  • Emit "readOnly": true only when field.readonly == True (omit otherwise).
  • Emit "format" for:
    • Email → "email"
    • URI → "uri"
    • Date → "date"
    • Datetime → "date-time"
  1. Risks / questions for mentors
  • field.readonly is static. Some editability may be dynamic (permissions/workflow).
    Question: Is it acceptable to expose only static readOnly here, or do you prefer a different mechanism/endpoint for dynamic editability?
  • For format, do you agree with the mapping above?
  1. If accepted, planned deliverables
  • Backend: implement + tests (test_types.py)
  • Frontend (Volto): optionally consume readOnly to disable inputs and format to select widgets/validation (only if desired by mentors)

Are you OK with adding readOnly + format to @types/<type> output as described?

2

This kind of positing don't belong here. Bring it to the related issue tracker and discuss there.

3

Thanks for the clarification :+1:
Understood — I will move the discussion to the issue tracker so it can be evaluated in the right place.

I’ll open an issue summarizing the findings and link it back here.