Module clp_validate 

Validating a class-level-permissions block, with upstream’s exact messages.

Upstream: validateCLP (SchemaController.js:271-399) and the four helpers it calls, validateCLPjson (:401-420), validatePermissionKey (:218-235), validateProtectedFieldsKey (:237-254) and validatePointerPermission (:422-442).

These messages are wire-visible. POST /schemas/:className and PUT /schemas/:className both reach here, parse-dashboard renders what comes back, and spec/Schema.spec.js asserts on the strings. Reproduce them byte for byte, including the quoting, which is inconsistent upstream: the unknown-top-level-key message has no quotes and every other message does.

Two things here are the reason this is a module rather than three lines in schema_api.

The two entity grammars are not interchangeable. Operations accept pointerFields, *, requiresAuthentication, role:<name> and an objectId. protectedFields accepts userField:<name>, *, authenticated, role:<name> and an objectId. Neither accepts the other’s spellings, and a shared validator gets it wrong in both directions.

The objectId grammar is a configuration input. ^[a-zA-Z0-9]{1,}$ normally, ^.{1,}$ when allowCustomObjectId is on (SchemaController.js:726-731). Hardcoding the first one silently rejects valid CLPs on a server configured for the second, which is why ClpValidation has no Default and the caller must state it.

Structs

ClpValidation

Everything CLP validation needs that is not the block itself.

Enums

ObjectIdForm

Which strings count as an objectId inside a CLP.

Unenforceable

Whether to refuse CLP features parse-rust validates but does not enforce.

Constants

VALID_KEYS

Top-level keys a CLP block may carry (CLPValidKeys, SchemaController.js:256-268).

Functions

validate_clp

Validate a CLP block against a class, and parse it.