[Meta] PII module suite

just a note.
PII stands for: Personally Identifiable Information

@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".

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?

if the settings should instead be moved into the Fields UI where site builders will manage their field settings already

This is already the case. Inline field settings exist and are the primary way for configuring fields. The main purpose of the overview page is to give Data Protection Officers (or similar roles) the ability to see their data as a whole, make decisions over which entities do and dont contain PII data and work their way through their site when retrofitting PII to an existing site or auditing their data (which can take a lot of time). And yes it also helps with configuring base fields which are not exposed by default.

But I like the approach of connecting visibility to the field_ui module. That makes a lot of sense to me.

In short, I think lets just get started and see where we end up. I am happy taking the name `pii_api` for the main module. We could still take the `pii` namespace for simplicity and put a few different submodules in that. However I've noticed that that namespace is already occupied: https://www.drupal.org/project/pii → - No code has been provided and there is just a readme file in the repo so we could ask them to give up the namespace but that might cause delays so I will leave that side of things with you. I can start writing the module and push it to a repo once one becomes available or we have finalised that decision.

Thanks for the clarification on the field ui side of things. It's great to see that it's already integrated and that the overview page is an additional tool with a specific purpose. That makes a lot of sense.

If in any way possible, let's keep in mind that we build this in a pluggable way. What I mean by that is that the properties "Right to access" and "Right to be forgotten" are coming from the other modules that build on top of the PII API. And even more such properties may come in from even unknown modules to date.

The extending modules for the 2 known properties, or at least the one about "Right to be forgotten" should also be able to configure the handlers on how to "forget" the data: delete, obfuscate, empty, etc.

Regarding the namespace, I've created 📌 Is this namespace PII available for an important use case? Active and will also ask the Drupal CMS leadership team to see if they can accelerate that process in case we don't get short term response.

jurgenhaas → credited j. ayen green → .

Good news, the PII Project → can now be used for this. Thank you @j. ayen green