User tests: Successful: Unsuccessful:
Pull Request for Issue #24190 (partial).
create an user custom field and set to yes the new option
create a remove privacy request
If a user custom field is marked as a privacy sensible data
when a user require to be removed and the admin perform the task, these fields values are delete
N/A
maybe
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_fields Front End Plugins |
I have similar feelings like Michael to have this in core only for the user context. But wouldn't it make sense to have this to all com_fields fields?
It's also possible that you have a com_contact connected to the user or an article with customfields and sensitive data.
Michael's approach would modify the custom fields xml on the fly if I understand it correctly, sounds like less unneeded impact.
beside this please update the PR with preapared statments and correct innerJoin syntax
Labels |
Added:
?
?
|
That's the reason why i've opened this as RFC, atm it seems logical to have the privacy related info only on com_user, but more use cases can help the discussion to see if there is a fit for com_contact fields or even com_content fields.
As we are in J3 no prepared statement, inner syntax fixed
The compliance team has prepared the following response:
Based on our first approach to include the custom fields to the anonymization/deletion functions, we think that Nicola's proposal goes in the right way.
What Michael and Harald suggested is, according to our team, an extension of this logic that could result to deliver an improved CMS in terms of compliance regarding all the data associated with the user's personal/sensitive information stored through the custom fields.
We think that in such features, things that are critical are:
As a result a Super User should (ideally) be the only one able to enable (or afterwards disable) the anonymization/deletion functions for the custom fields (even if these are related to the Contacts or the Articles) and when a user requests for their data to be anonymized/deleted then these elements should be also anonymized/deleted (what each Webmaster think fits better to his compliance plan).
This is a great decision towards the direction of the Out-of-the-Box logic of Joomla! CMS.
Such features should be by default disabled and and accessible by Super User (SU) only.
That the control of these plugins is only under SU control.
Is that possible with the current architecture?
This is is an add-on capability that should be enabled through the use of plugins (and before this goes over anyone's heads, think of how the user profile plugin extends the core user data; that is exactly the integration I am thinking of), architecturally this should not be a core feature of the com_fields data model. The site owner then has the capability to decide whether this type of feature should be enabled globally or on a contextual basis or even on a per-field basis (you might write a fields plugin that should always have this option turned on).
That is how progressive enhancement works. You don't hardcode integrations into everything, and if you have to resort to that, then your architecture does not have the flexibility required to progressively enhance the core platform and you need to invest time in improving the core architecture (note how com_privacy is almost 100% plugin driven, there is no part of it or its existence hardcoded into any other component).
Such features should be by default disabled and and accessible by Super User (SU) only.
a little improvement the privacy related param can only be setted by a SuperUser now.
Is that possible with the current architecture?
yes
architecturally this should not be a core feature of the com_fields data ....That is how progressive enhancement works. You don't hardcode integrations into everything...
I can agree ..... but still looking for something more than an 1 little man effort or any kind of architectural plan/design
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-02-12 19:28:43 |
Closed_By | ⇒ | alikon |
Something feels weird about adding this field to the core data model of com_fields. This feels like it should be hooked in using plugins to modify forms (assuming the right events are still dispatched in this context). Especially if you are intending for it to only apply to one context (user account data), as is this makes all custom fields in all contexts aware of the change.