Contrib.social

[Meta] PII module suite

Open on Drupal.org →
Created on 1 April 2025, 24 days ago

Problem/Motivation

The submodules fields and task in the GDPR → module provide functionality that's required for the advanced privacy recipe in Drupal CMS. Those 2 submodules have been developed and maintained by @yanniboi, and he is on board with the idea of extracting them from GDPR and turning them into an independent suite of modules that can be used for Drupal CMS but also elsewhere and for other purposes if needed.

Proposed resolution

There should be an API module, which allows site builders to define entity fields or even full entities as containing sensitive data that belongs to a specific user. This API module should also allow the configuration of what should happen with their content when certain actions (reporting, exporting, deleting, etc.) will be performed. This configuration should be module-agnostic, i.e. this configuration should be abstracted away from the use cases that we currently have in mind.

Two other use cases should go into separate modules that require the above API module. Either both of those use cases get addressed together in one module, or one module for each. This needs to be discussed. The use cases are:

  • Allow users to request a report of data that's stored from or about them.
  • Allow users to request all their data being deleted.

Both of those not only require some CTAs, confirmation forms, and rendered pages to interact with the user, they also require some task management, maybe review steps, and persistent logging to be reported to the authorities if needed.

Next steps

  • Defining names (human-readable and ID) for each module
  • Define dependencies
  • Write down use cases for each module
  • Finalize specs for each module
  • Create the module pages
  • Implement the modules
  • Testing
  • Writing documentation
  • Adding it to Drupal CMS
  • Providing marketing material
📌 Task
Status

Active

Component

Track: Privacy

Created by

🇩🇪Germany jurgenhaas Gottmadingen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jurgenhaas
  • Comment 24 days ago →
    🇦🇹Austria Grienauer Vienna

    just a note.
    PII stands for: Personally Identifiable Information

  • Comment 22 days ago →
    🇬🇧United Kingdom yanniboi UK

    @grienauer thanks for that. You raise a good point. If we end up using PII in the terminology for this suite I would suggest using `pii` in machine names and the full Personally Identifiable Information in human readable labels wherever possible.

    @jurgenhaas thanks for starting this discussion. I am fully on board with this. The only real question I have with regards to implementation is do we want to decouple the api module from the user interface for configuring it (like views/views_ui) or would it make sense for them to be bundled together?

    Other than that I will try to keep an eye on this thread but please do reach out to me once it is time to start building code and I can probably do the first run at the refactor of gdpr into "pii suite".

  • Comment 18 days ago →
    🇩🇪Germany jurgenhaas Gottmadingen

    I am fully on board with this.

    This is exciting.

    The only real question I have with regards to implementation is do we want to decouple the api module from the user interface for configuring it (like views/views_ui) or would it make sense for them to be bundled together?

    That's a great question. Thought about it for the last few days but can't find a real preference.

    In the GDPR module, the UI is a page on its own (in /admin/reports if I remember correctly) and that shows everything together on one page. I was wondering, if the settings should instead be moved into the Fields UI where site builders will manage their field settings already. That way they would find the extra settings more intuitively? We wouldn't have to have our own overview page anymore, instead, the extra settings would show up in the config form for each field. But that would make it hard for base fields, right?

    I'm saying all that because if we could move all the API functionality close to the Field UI, there wouldn't be a need for a separation between API and UI. People who want to hide all this from their users could just disable Field UI and that would also hide the UI of the PII API.

    With regard to naming modules, I really like pii_api as the machine name for the API component. The human readable name can still be adjusted as we go.

    But I'm struggling with proposals for the other 2 components (which may only be 1 module?). @yanniboi do you have any proposals for that?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024