Assembles a schema-property payload (a leaf type, or an array of that
type) from resolved field values, validating type and the
enumValues/enumTitles pairing along the way (throws FrodoError).
date/time/datetime/duration are all type: "string" with a
format field under the hood — confirmed against a type created via the
Admin UI's own property-type picker (which offers exactly these four
alongside String/Number/Boolean/Object), including the exact format
values ("date", "time", "datetime" — not the more common
"date-time" — and "duration"). object is always written as a bare
{ type: "object" } with no properties/order, matching a live example
of an empty object property — a structured object property (its own
nested set of sub-properties) is a deliberate scope choice, not a
technical limitation of the property itself: these fields only cover a
flat property definition, so a structured object needs a verbatim
readSubConfigEntity/importSubConfigEntity round trip instead, which
writes the definition as-is and has no such restriction.
default/enum/enumTitles sit on the leaf type node (so they land on
items for an array property, constraining each element) — confirmed
against a live enum property. isVirtual/onRetrieve/onStore/
queryConfig sit at the top level instead, confirmed against two live
managed-object examples: a pure RDVP (relationship-derived virtual
property, queryConfig only, no script), and a script-derived virtual
property (onRetrieve only, no queryConfig) — both live entirely inside
schema.properties, the same place create/update already read and write,
so no new API surface was needed for either.
Note on the type validation below: it runs against whatever ends up in
fields.type, including a value merely carried through unchanged from an
existing property's current definition during an update (see
extractManagedObjectSchemaPropertyFields) — so updating so much as
the title of a property whose type isn't one of
MANAGED_OBJECT_SCHEMA_CREATABLE_PROPERTY_TYPES (e.g. one
hand-crafted outside this flat-property path) fails here too. That's a
deliberate tradeoff for a single, consistently-enforced source of truth
rather than validating only caller-supplied overrides; a property in that
situation still has the unrestricted readSubConfigEntity/
importSubConfigEntity verbatim round trip available as an escape hatch.
Assembles a schema-property payload (a leaf type, or an array of that type) from resolved field values, validating
typeand theenumValues/enumTitlespairing along the way (throwsFrodoError).date/time/datetime/durationare alltype: "string"with aformatfield under the hood — confirmed against a type created via the Admin UI's own property-type picker (which offers exactly these four alongside String/Number/Boolean/Object), including the exactformatvalues ("date","time","datetime"— not the more common"date-time"— and"duration").objectis always written as a bare{ type: "object" }with noproperties/order, matching a live example of an empty object property — a structured object property (its own nested set of sub-properties) is a deliberate scope choice, not a technical limitation of the property itself: these fields only cover a flat property definition, so a structured object needs a verbatimreadSubConfigEntity/importSubConfigEntityround trip instead, which writes the definition as-is and has no such restriction.default/enum/enumTitlessit on the leaf type node (so they land onitemsfor an array property, constraining each element) — confirmed against a liveenumproperty.isVirtual/onRetrieve/onStore/queryConfigsit at the top level instead, confirmed against two live managed-object examples: a pure RDVP (relationship-derived virtual property,queryConfigonly, no script), and a script-derived virtual property (onRetrieveonly, noqueryConfig) — both live entirely insideschema.properties, the same place create/update already read and write, so no new API surface was needed for either.Note on the
typevalidation below: it runs against whatever ends up infields.type, including a value merely carried through unchanged from an existing property's current definition during an update (see extractManagedObjectSchemaPropertyFields) — so updating so much as the title of a property whose type isn't one of MANAGED_OBJECT_SCHEMA_CREATABLE_PROPERTY_TYPES (e.g. one hand-crafted outside this flat-property path) fails here too. That's a deliberate tradeoff for a single, consistently-enforced source of truth rather than validating only caller-supplied overrides; a property in that situation still has the unrestrictedreadSubConfigEntity/importSubConfigEntityverbatim round trip available as an escape hatch.