Release v16.9.1

Summary

[PII] was only reliably honored on values sitting directly on an event or read model. Once a personal value was composed into something — held by a value object, or put in a list — its classification could be lost on the way into the JSON schema, and the value was then persisted in the clear. Because nothing was encrypted, reads succeeded and the gap stayed invisible until a compliance release failed against a document that turned out to be plaintext.

[PII] is now followed wherever the value ends up: on a concept nested inside a value object, on a concept held in a collection, and on a whole value-object type. A marker that resolves to an object is pushed down to the individual values it holds, so each stays independently encrypted and the document keeps the shape the read model materializes from.

Added

• [PII] can now be applied to a value-object type, classifying every value it holds wherever that type appears.
• [PII] can now be applied to a property typed as a value object, with the same effect scoped to that property.

Fixed

• A [PII] concept held in a collection is now encrypted. It previously lost its classification and was stored in the clear, even though the same concept type was encrypted as a scalar.
• A compliance marker covering a whole value object now releases back into an object instead of a raw string, which previously left the read model unable to materialize.
• A property covered by a compliance marker as a whole is no longer also descended into, which encrypted members whose mutations were discarded and, on release, decrypted members that were never separately encrypted.

Removed

• PIIAppliedToNonConceptAsType — applying [PII] to a type that does not derive from ConceptAs<T> is now supported, so the exception can no longer be thrown.