Is this active?

[back-2-95]

Hello, ended up here from https://www.drupal.org/project/gdpr/issues/2931820

I think the approach here is simple and maintainable. But I must ask if this is in any active development?
There is one PR for the UI where the discussion has also ended.

My 2cents is that creating UI is just nice-2-have and might revert attention from actual stuff. That said I'd say configuration (via $settings.php) is better way to configure your project's data anonymisation. That way we could avoid content producers etc from tinkering this configuration + avoid the need for exporting confs related to this.
Only developers should conf these.

Looking forward for reply.

[anotherjames]

FWIW, I had a small amount of involvement here, and probably still have some interest, but our company shifted our priorities elsewhere.

My 2cents is that creating UI is just nice-2-have and might revert attention from actual stuff. That said I'd say configuration (via $settings.php) is better way to configure your project's data anonymisation. That way we could avoid content producers etc from tinkering this configuration + avoid the need for exporting confs related to this.
Only developers should conf these.

On this - you do need to watch out to catch anything new with its own tables & fields that could be capturing PII. For example, new webforms or fields. Whilst only developers would create those on many projects, it's very likely that many non-developers set those up on other sites. So a UI still has a lot of value on those; although I recognise that those might not be the primary audience of this tool.

[back-2-95]

Yeah, true. I might have made my statement from our point of view where we control large Drupal sites.
Ofc in Drupal you can differentiate the "engine" and the "UI" to e.g. submodules.

Similar to CDN module. The actual "engine" is the cdn module itself and then it has submodule "ui" which you can enable/use if needed.

[back-2-95]

I need to test this. And if it works I might Fork the repo.

[robiningelbrecht]

@back-2-95 You could also add PR's instead of forking? Keep things centralized?
Also could give you permission to merge if you are interested in maintaining this repo?

[back-2-95]

@robiningelbrecht What do you think about your own interest/time to evolve this?

Another question: how I include this in my project via Composer? Do I need to setup additional repository in composer.json?

[robiningelbrecht]

@back-2-95 My daytime job does not involve Drupal anymore, so I'm not planning on actively maintaining this.
But I would still be interested in merging PR's and keeping this thing up to date by doing so :)

You should be able to install this by executing composer require drupal/gdpr_dumper

[anotherjames]

I'm happy to keep an eye out and help review things too, though only with a certain level of capacity to do so! Small changes at a time can work :-)

[back-2-95]

I did try that req but got Could not find a matching version of package drupal/gdpr_dumper.

We at https://github.com/druidfi do still quite many Drupal projects so this in an interest for us. We have also done some forks like this before: https://github.com/druidfi/mona-plugin

I'll discuss with my colleagues how we would like to procede.

[back-2-95]

In any case, it might be a good idea to include LICENSE file on your repo.
Example from our repo https://github.com/druidfi/mona-plugin/blob/main/LICENSE

[back-2-95]

@robiningelbrecht here is a small PR #6

[back-2-95]

@robiningelbrecht followup PR #7

[back-2-95]

@robiningelbrecht as you seem to be familiar how Drush commands work, what do you think about drush sql-sync command?

How that could also utilize gdpr dump?

[robiningelbrecht]

@back-2-95 drush sql-sync is mainly used to import SQL files, so I don't see how gdpr dump (which dumps data to an SQL file) can come in play?

[back-2-95]

E.g drush sql-sync @source @self basically makes ssh connection to @source, makes drush sql-dump > some_tmp_path there and then transfers the file back.

So I was thinking maybe the custom code can modify things some how.
E.g. if there is a flag drush sql-sync --gdpr ... it would be able to use sql-dump-gdpr command instead.

[robiningelbrecht]

If we would want to provide that kind of functionality, we would have to add a new drush command:
drush sql-sync-gdpr @source @self for example and inherit most of the functionality from the original command.

I think that would be the best approach.

[anotherjames]

That approach would rely on this package being available on the source database, which when connecting remotely, I'm not sure you can guarantee? I'd be concerned about implying that the dump is GDPR-safe, if it might not be.

Or maybe that's not valid, I'm not totally sure. Just wanted to flag the thought up, in case.

[back-2-95]

Yes this package/module needs to exist on both ends. We have Drush itself on projects with Composer so with that we ensure every environment has same Drush version and also other packages too.

[back-2-95]

The "challenge" with GDPR here is that altering the dump must happen on source before transfer. As you cannot transfer the user data to your computer and then create compliant dump. Transfer of user data has already happened.

So options are:

• support gdpr dump with sql-sync
• use scripts like: execute gdrp-dump on remote, then scp the dump to local
• use some middle service which e.g. every night creates and fetches the gdpr compliant dumps to some location where developers can access them