marcus_johansson → credited yanniboi → .
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.
All resolved!
yanniboi → created an issue.
@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".
yanniboi → created an issue.
jurgenhaas → credited yanniboi → .
penyaskito → credited yanniboi → .
yanniboi → made their first commit to this issue’s fork.
Once a mysql user has been created with a password you just have to reference the user, not include the password again. The existing command will error without my change.
I've created a PR to fix this. :)
I can confirm this issue and I would suggest using the "administer feedback message entities" permission for the collection page.
We've started looking at contributor proposals :)
If you want to contribute to this please link your proposals from gsoc (https://summerofcode.withgoogle.com/) here.
I cant actually see what change you made in that fork, but I assume you mean change:
Drupal::moduleHandler()->loadInclude('install', 'decoupled_auth', 'decoupled_auth');
This has actually already been fixed in the 2.x and 3.x branches. Which branch are you trying to install?
Patch attached to provide the logged in user context to all blocks in the dashboard.
Tests are failing/passing as expected:
@plopesc patch 13 is an empty file :P
Tests failed on coding standards
I'm attaching a js test to cover the changing and saving of a dashboard with a form block present.
I am assigning this to myself and will try to work on this during DrupalCon Lille. If I dont make any progress I will unassign myself again.
What @hansfn is saying is true, it is very simple to create a content type and a views block. However, I very frequently have clients that just want to insert a specific bit of helper text into a UI. Maybe its a clarification about what should and should not be done or its just a temporary holding message. If there are several columns and rows on a dashboard there might be several blocks with adhoc text to be added in different areas.
An additional (huge) benefit of having a specific block time with config fields means that the text can be exported to site config and deployed with the block instances which avoids having to have to add the copy as content on production after a new feature is deployed.
yanniboi → created an issue.
penyaskito → credited yanniboi → .
I am not sure if @dabley's issue is related, however it looks like since mailchimp-api-php has release release candidate 6 with the API fix included we can now update the version dependency of mailchimp module.
yanniboi → created an issue.
Patch attached
yanniboi → created an issue.
yanniboi → created an issue.
Thanks a lot
yanniboi → made their first commit to this issue’s fork.
Looks great!