EDU-17349: document PII masking and unmasked retrieval#1637
Open
PedroAntunesCosta wants to merge 7 commits intomasterfrom
Open
EDU-17349: document PII masking and unmasked retrieval#1637PedroAntunesCosta wants to merge 7 commits intomasterfrom
PedroAntunesCosta wants to merge 7 commits intomasterfrom
Conversation
PedroAntunesCosta
added
the
documentation
PedroAntunesCosta
added
the
documentation
|
Thanks for your contribution. The .json file will be checked now with Spectral. |
Add new POST /personalData endpoint for configuring which entity fields contain personal data, with data subject ownership support. Add openData query param to read endpoints for unmasking, and dataSubject query param to write endpoints for GDPR compliance. Remove previous v-pii schema approach per the updated technical proposal.
Rename openData to unmasked, add audited reason parameter for reads, remove legacy dataSubject query param from writes, and require data_subject_field in personal data configuration schema.
Rename unmasked query param to _unmasked to match the leading-underscore convention of other reserved params, drop the reason param, switch the configuration endpoint to PUT with PascalCase Fields/SubjectIdField body, add a GET endpoint to retrieve the current configuration, and document the 12h reprocessing lock with a 423 response.
Allow Read only documents, Insert or update document, and Full access to all documents resources on Get personal data configuration, matching Get schemas. Configure personal data fields already matches Save schema by name (Master Data administrator only).
PedroAntunesCosta
requested review from
Isabella-Veloso
and removed request for
AndersonSM and
filipewerneck-vtex
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Documents secure personal data in Master Data v2.
API contract (OpenAPI)
Personal data configuration
Path:
/api/dataentities/{dataEntityName}/personalDataNew
GETGet personal data configuration — returns the current configuration. Permissions match Get schemas.New
PUTConfigure personal data fields — replaces the configuration. Permissions match Save schema by name (Master Data administrator).Fields(array of strings) — fields that contain personal data. Stored separately with encryption and special data residency.SubjectIdField(string) — the field whose value identifies the data subject (owner of the personal data) in each document. Required for compliance with data subject requests (e.g., right to be forgotten).Saving a new configuration triggers a background re-tokenization of all existing documents. While this runs, the PUT is locked for the affected entity for up to 12 hours and returns
423 Locked.Document reads (masked by default)
Get document, Search documents, and Scroll documents accept:
_unmasked(boolean, optional, defaultfalse) — whentrue, returns original values for personal data fields. Only takes effect if the entity has personal data configured; otherwise ignored. Underscore prefix follows the convention of other reserved params (_fields,_where, etc.).Document writes
No new query parameter on create/update. The data subject is identified via the
SubjectIdFieldvalue present in each document body.Search
Search documents description notes that personal data fields only support exact match when used as filters (when indexed via
v-indexed).Index / tags
API overview index includes a Personal Data section (GET + PUT); new Personal Data tag for both endpoints.