? ? Pending

User tests: Successful: Unsuccessful:

avatar alikon
alikon
15 Aug 2019

Pull Request for Issue #24190 (partial).

Summary of Changes

  • added a radio button on fields (yes for delete sensible data) default no
  • added the code to delete user custom fields data on privacy remove request

Testing Instructions

create an user custom field and set to yes the new option
create a remove privacy request

Expected result

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

Actual result

N/A

Documentation Changes Required

maybe

avatar alikon alikon - open - 15 Aug 2019
avatar alikon alikon - change - 15 Aug 2019
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 15 Aug 2019
Category Administration com_fields Front End Plugins
avatar mbabker
mbabker - comment - 15 Aug 2019

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.

avatar HLeithner
HLeithner - comment - 15 Aug 2019

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

avatar alikon alikon - change - 16 Aug 2019
Labels Added: ? ?
avatar alikon
alikon - comment - 16 Aug 2019

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

avatar roland-d
roland-d - comment - 22 Aug 2019

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:

  • 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. Otherwise another user could turn off the plugin without a SU knowing this. Personal or/and sensitive data might be left behind.

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.

avatar brianteeman
brianteeman - comment - 22 Aug 2019

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?

avatar mbabker
mbabker - comment - 22 Aug 2019

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).

avatar alikon
alikon - comment - 23 Aug 2019

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 ?

avatar alikon alikon - change - 12 Feb 2020
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2020-02-12 19:28:43
Closed_By alikon
avatar alikon alikon - close - 12 Feb 2020

Add a Comment

Login with GitHub to post a comment