Through core this can already be accomplished using the "User - Profile" plugin (use the terms of service options).

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19078

closed as Issue can be accomplished by Core.

@mbabker the core TOS option doesnt satisfy the GDPR regulations as you have to display the information on the page not in a seperate link

Set to "open" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/19078

reopened for further Discussion.

This can be done via a template override. There are several rules and regulations that Joomla doesn't obide by using options, but if the user can perform a template override, then this is fine.

E.g, there are certain a11y standards that in some countries adhere to, that by default Joomla 3 doesn't support at all, but can still be built in.

1. this cant be easily done with a template overrride
2. this is a global not national issue

Well right now what you are basically saying is to adhere to GDPR any site that might potentially offer user registration has to have a mandatory wall of text and agree to terms checkbox on their registration form in case even one EU resident registers.

Which is asinine because a link should be more than enough instead of the mandatory wall of text inlined into the page.

@brianteeman - seemed pretty easy: https://jsfiddle.net/xaa1z39e/3/

Just create an override and add the code

Which is asinine because a link should be more than enough instead of the mandatory wall of text inlined into the page.

The law is an ass

Another alternative would be to display the TOS article within a modal as opposed to a separate link, assuming that still considered the "same page"

seemed pretty easy: https://jsfiddle.net/xaa1z39e/3/

Just create an override and add the code

that would certainly have been above my skillset. it uses js and i dont understand any

@brianteeman - You could even go for a "CSS only" solution if you're not comfortable with JS:

https://jsfiddle.net/o0dpzwjw/1/

Would the alternative in my comment above be ok to go with?

Not for me. It should be part of the core. I will submit a pr to add the required support to the user profile plugin. Won't take more than five minutes and then it is available for everyone whatever their skill level to use.

In which case I'd suggest initially disabling the submit button if they have the "GDPR" option enabled. This will prevent users registering who haven't checked the box.

you only need to make it a required field

imho it should be in the Registration form not the user plugin.

@Webdongle easy mistake to make but the user profile plugin is used in the registration form

@brianteeman easy mistake to make but the user profile plugin is an optional addition to the registration form. The suggestion I made was for the T&C box to be integral with the Registration form not part of a plugin which is an optional addition.

After all a T&C box is a separate entity to additional user profile info like a captcha is a separate entity. Therefore a T&C box should be an option in the Registration form (like recaptcha is) not an option in a plugin that is optional to add more user info.

It might (at first glance) appear pedantic but when looked at closely ... seeing that the T&C box is a separate entity (like a recapcha box is a separate entity) is obvious. Moving the T&C box from the plugin to the Registration form ... turns it from an indirect option into a direct option for the webmaster.

Also by placing the T&C box in the registration form it could also make it mandatory without the webmaster needing to activate the user plugin and hide all the other fields that are in that plugin.

Bottom line a T&C box is not part of extra user details and does not rightfully belong in the user profile plugin.

We are not breaking B/C and moving options around for the sake of pedantry. In case you forget those types of changes were part of the reason so many people hated the 1.5 to anything newer migration, because there were a lot of pedantic changes with zero benefit.

Here we go again. It could be done without breaking backward capability.

Moving an option from one extension to another is a B/C break. Period. There is no mitigation layer for it. Any code relying on that option in the plugin would be broken unless you are saying to duplicate the code, which still breaks any code relying on that option because users may no longer be setting the option at that space. And we are not going to get into the business of hardcoding com_users to update a specific plugin's parameters, that is counter to our system design where plugins are supposed to be able to extend system functionality without a component being aware of its presence.

Any code relying on that option in the plugin would be broken unless you are saying to duplicate the code,

Nope not duplicate the IF would depend on a different variable and be independent of that of the field in the plugin. It doesn't have to be moved just also added separately as an option for the webmaster to use if they are not using in the plugin.

But if having a T&C box option twice then how about putting a Privacy Policy box (or statement in the Registration form ? So that user had to tick to acknowledge they agree to the Privacy Policy.

But if having a T&C box option twice then how about putting a Privacy Policy box (or statement in the Registration form ? So that user had to tick to acknowledge they agree to the Privacy Policy.

It is still a logical duplication. Can you really agree to one of the policies without the other at that point?

Nope not duplicate the IF would depend on a different variable and be independent of that of the field in the plugin. It doesn't have to be moved just also added separately as an option for the webmaster to use if they are not using in the plugin.

It is not that simple. If you introduce a new attribute to the base user class and all the stuff in com_users, you are breaking all existing code either using that particular plugin or using a similar approach to add similar functionality. By introducing the attribute into the base user class and com_users, there are several code paths that must be accounted for (a site not requiring ToS, a site requiring ToS, if a site changes their ToS, etc.) in addition to a migration path for that attribute (if added to the base user class does it default on true meaning all accounts are arbitrarily agreeing to non-defined terms, does it default to false forcing all users on all Joomla sites the first time they log in after the fact to go through a process the site admin may not even be aware of?). How does such a move affect extensions in the ecosystem interfacing with or replacing com_users or the base user class in the PHP API?

The functionality already exists. From the end user perspective, there is no difference if it's hardcoded into the registration form or added through a plugin. From a site manager perspective adding it through a plugin offers a lot more flexibility with the overall workflow and is unbound to any changes in the core data schema.

It is more trouble than it is worth to move it for some semantics at this point.

So in theory a plugin could be written that

1. Placed a Privacy statement in the Registration form (the string in a language file)
   and
2. Has a check box in the Registration form that had to be ticked. Or more simply a field that had to contain a specific word like 'agree' so it matched the value of a constant (Which could also have the string in a language file)
   ???

Yes. Basically exactly what the user profile plugin does. Except apparently for GDPR compliance you'd need to change the part about a linked TOS article to either a blob of text to show on the page.

Much easier to simply add it to the user profile plugin. That way you have both tos and gdpr in the same place

That would appear to be the easy option. The only minus for that is if the webmaster only wanted the gdpr they would have to change the other plugin field settings to Disabled.

I get that
The gdpr is a 'lump of text' not t&c or privacy policy.
That it is to be added to the Registration form using a plugin.

But I maintain that it is a separate entity to additional user fields. And therefore should not be slotted into the user profile plugin alongside the additional user fields.

imho it should be treated as a separate entity (like the recaptcha) and given its own plugin.

Can Info by https://volunteers.joomla.org/teams/compliance-team help?

See also
http://www.consentcheq.com/wp-content/uploads/2016/12/Technical-Requirements-of-the-GDPR.pdf

@infograf768
That pdf appears to be produced by a company who make money by selling 'solutions' to help websites comply with the regulations. And appears to be part of their sales material and therefore may exaggerate certain elements. It only quotes in part and is (for a large part) their interpretation. http://www.privacy-regulation.eu/en/ gives it in full

this isnt the place to discuss the interpretation of the gdpr or external solutions. As the core all we can do is to provide a basic framework for someone to implement on their site and customise as appropriate. There can never be a one size fits all solutuion

As stated before I will submit a PR over the weekend

It appears pointless creating a PR when there are still unknowns.
It is not known if the gdpr statement is mandatory in the Registration form
It is not known if the gdpr statement needs to be a permanent article that resides in the site and needs also to be accessed from a menu item.

There can never be a one size fits all solutuion

No but some things are required ... like notifying a user if their information has been changed or deleted http://www.privacy-regulation.eu/en/article-19-notification-obligation-regarding-rectification-or-erasure-of-personal-data-or-restriction-of-processing-GDPR.htm . Perhaps there should be something in Joomla core to send an email.

There is no one size fits all but if notification of change or deletion is built into Joomla core then that might might make Joomla more attractive (to potential users) than its competitors. Perhaps a plugin could trigger an email if a user Profile was changed or deleted ?

Not known by you doesnt mean not known by those of us who have studied the regulations and attended seminars to ensure that we are informed and able to support our clients

It would be trivial to create a custom field plugin that displayed a checkbox, some text and disabled the attached form until the box was checked. No core changes required. The only thing to be done would be to create the custom field, name it, attach text and set the access to guest.

It would be easy enough to make that text appear in a modal as @C-Lodder suggested. With this type of field, an admin could require a user to jump through as many hoops (checkboxes) as they wanted before the form could be submitted.... GDPR, TOS, Beelzebub Soul Release Form, First Child Waiver....

@Webdongle - such a profile change plugin already exists.

@stutteringp0et it would be logical to add it to the user profile plugin as that already contains a tos agreement and the plugin garhers personally identifiable data so it would be required ther

Well, I'm writing the plugin anyway. An arbitrary number of required agree fields seems like a good idea to me.

it would be logical to add it to the user profile plugin as that already contains a tos agreement and the plugin garhers personally identifiable data so it would be required ther

The user Profile plugin is optional but by putting the gdpr requirment there you are forcing the webmaster to use that plugin. Also the other fields (when the webmaster didn't want them) would need to be edited.

Well, I'm writing the plugin anyway. An arbitrary number of required agree fields seems like a good idea to me.

Yes that sounds like a good idea but it only goes part of the way. What about notifying the user when their profile is changed or deleted ? Or when the way the data is handled changes ? http://www.privacy-regulation.eu/en/article-19-notification-obligation-regarding-rectification-or-erasure-of-personal-data-or-restriction-of-processing-GDPR.htm . Surely without without that any gdpr provision (n Joomla core would be as useful (to he webmaster) as chocolate teapot.

There are a lot of amateur users who have hobby/charity/community websites that need a good working solution because they can not afford to buy 3rd party extension. A good working solution is needed by those users ... not something that pays lip service.

Look up the profile history plugin in the Jed. It notifies users on field changes - on both custom and profile field types

As it seems that nothing will ever satisfy @Webdongle (mainly due to ignorance of the regulation) I will just keep my solution to my users

@brianteeman

Really ? You would deprive the whole community of the PR (that you promised to produce by the weekend) just because in my "ignorance" I post from a non professional point of view. If you are that upset with my point of view then perhaps you might lock this thread like you did when you disagreed with the other thread where you refused to listen to my contribution.

Your personal attacks on me are very upsetting. If you wish that I no longer try contributing to the community then say so outright and stop making personal attacks on me.

Guys, if we can focus on the issue, GDPR compliance is required in May...

I'll have a field plugin finished shortly. When properly deployed, a user will be required to check the acceptance radio button, with a linked (modal) article - and you can use as many of the fields as you want, linked to whatever terms article you want. The field data will store the date, time, and ip address of the computer accepting terms. Required parameters are altered depending on who/where it's being viewed (user front end - required, admin backend - not required)

Some (many) sites don't need it - best to make it an optional extension instead of forcing compliance on sites that aren't required to comply. e-Privacy isn't part of Joomla - why should any other regional law be part of it?

I agree on the fact that such a new feature should be totally independent from the User Profile. It would make it much more useful and not confusing at all.

I've got a solution pending approval on the JED

I thought you joined this thread for a core addition to Joomla. I didn't realise it was a platform for advertising 3rd party extension solutions.

Carpe potestatem!

@Webdongle agree, thought too.

Thought too...

This same thing was discussed regarding the e-Privacy directive (Cookie Control #19011 ) and it seemed this was traveling along the same road. If the stated goal (keep the core light) remains true - then this is going to inevitably become the responsibility of 3rd party developers to solve.

@stutteringp0et

No active decision was made one way or another in that thread. Nobody offered to create a solution because 3rd party extensions already existed.

In this thread you joined in and said you were writing a plugin. As this is a conversation in github for Joomla issues and Joomla solutions ... it follows that any new solutions (proposed in the thread) should be PR's not self promoting adverts.

In addition to that your intervention will take the focus away from how Joomla core should handle the issue.

So, @mbabker @brianteeman @wilsonge @infograf768

1. Is this going in core? Yes or no?
2. If so, separate plugin or part of the profile plugin?

Please make a final choice and I'll just do it myself

If I get a vote, Yes in core, separate plugin. Just my thoughts.

Hope everyone here had a wonderful holiday!

Can I ask if there are any updates?

-Michele

I haven't had time to review over the Christmas period. It's on my list of things to cover this week :)

@brianteeman wrote (16 Dec 2017):

   this is a global not national issue

I beg to disagree. this is a "national" (or perhaps better described as a "political" issue) and not a global one.

It is global as it applies to anybone who has users in the EU.

But I don't live in the EU. What is it about Australia that means we're not part of the global community? Are we aliens from another planet or something? :P
As I wrote before, we're discussing politics, not geography.

The way the law is written is that it applies to you if you have anyone from the EU signing up to your website. Wether that is enforcible is a different matter

That sounds like a poorly made plan that will result in websites blocking EU visitors rather than comply with laws made by politicians and bureaucrats they did not elect.

Should be fun to watch.

@brianteeman: as you say, whether the law is enforceable (globally, that is) is another matter and, again, this is about politics and not about geography and IMHO outside the purview of website development. I agree that there are features built into Joomla that don't apply to everyone (e.g. LDAP authentication) unless you require them. There are features that are built into Joomla that are required by everyone (e.g. website security) or in order to be compliant with ISO standards ... and a lot of those things are still to be built (e.g. accessibility for blind/visually impaired users regardless of your visual acuity) for site administration. If there are developers who want to build GDPR "active consent" into Joomla then that's probably a good thing; whether people will require it (or use it) is another matter.

I suspect this shouldn't be a case of drop-everything-and-jump-whenever-there's -a-change-in-the-political-wind (and should this item be on the roadmap for J! 3.9?) but I commend the good work that people are doing.

Cheers. ;)

This is something that affects everyone who has users in the EU. And it should be dealt with fully in the core not just payed lip service to.

OK I've finally had a chance to read through this (I'm really sorry I've barely had a chance for Joomla in the last month), the christmas rush is slowly dying down. Given what Brian describes as the scope

it applies to anyone who has users in the EU

which is also what I was taught at the GDPR training course I went on at MongoDB London, I think this is a global issue too. I'd be more than happy to see a sensible GDPR plugin. We need to be clear that it might change over time as people start to standardise on standards however.

Also FWIW at the training course I was on supposedly the EU will ban you from storing users personal data in certain countries that don't comply with GDPR - so I'm going to really enjoy watching how that works xD But I'd much rather be ahead of the curve than behind it.

@wilsonge
Is that a separate plugin to the user profile plugin ?
If so then should it also trigger emails to all users if the site's gdpr wording changes ... or email a user if the user's profile is edited ?

Correct. This would be a dedicated plugin to ensure we are compliant with GDPR. Honestly I'd need to get advice on the email triggering thing. I've not heard that one before. But neither to I pretend to be close to an expert on all the ins and outs (I was mainly attending the training in my work capacity to learn about impacts on biometrics)

3rd party extensions already exist to handle all of the GDPR requirements...

@stutteringp0et - yes, a plugin you've made yourself. However nobody knows if it meets the requirements or if the code is any good.

I see it as 2 parts. Active consent (easy), and profile value change notifications (fairly hard). There are separate extensions to handle each.

@wilsonge

The controller shall communicate any rectification or erasure of personal data or restriction of processing ...
http://www.privacy-regulation.eu/en/article-19-notification-obligation-regarding-rectification-or-erasure-of-personal-data-or-restriction-of-processing-GDPR.htm

The rules appear to be more complex than can be solved with just a plugin ?

Name an action in Joomla that cannot be hooked with a plugin as it relates to GDPR compliance.

@mbabker
Would one plugin

• Allow an Article with the gdpr to be displayed during registration ?
• Notify all users if the Article was altered
• Notify individual users if their profile was altered
• Allow a user to delete their account

Or would it need to be separate plugins for each ?

A system plugin (because that is the only plugin group loaded on every request) can hook everything in the system. It is all reliant on extensions dispatching events for those actions.

Allow an Article with the gdpr to be displayed during registration ?

Already possible, see ToS setting in profile plugin.

Notify all users if the Article was altered

Use onContentAfterSave event.

Notify individual users if their profile was altered

Use onUserAfterSave event.

Allow a user to delete their account

Joomla is not at a point where it can enable users to safely delete their accounts, so even with GDPR regulators breathing down my neck my solution to this would be contacting the site owner through another mechanism to discuss account removal (part of the issues with that are already discussed in this thread, no need to rehash them). When Joomla can allow this functionality safely, then it should be exposed as part of the core component and not through a plugin.

@mbabker

Joomla is not at a point where it can enable users to safely delete their accounts, so even with GDPR regulators breathing down my neck my solution to this would be contacting the site owner through another mechanism to discuss account removal (part of the issues with that are already discussed in this thread, no need to rehash them). When Joomla can allow this functionality safely, then it should be exposed as part of the core component and not through a plugin.

So a plugin would not be sufficient to do everything because of a user deleting their account.

As for the things that could be done with a plugin hook ... would they be done in one plugin or separate plugins ?

The rules appear to be more complex than can be solved with just a plugin ?

You're not explaining how the "rules appear to be more complex than can be solved with just a plugin". At least in the case of a user account, as already pointed out in this thread, it is a lot more involved than just DELETE FROM #__users WHERE id = $user. This is not a problem unique to Joomla and not one that is just solved by slapping a plugin on a site or adding a delete button to the core edit profile page because the user account is tied to a lot of things and if you arbitrarily start deleting content associated with that user account you potentially wreak havoc on a website (imagine the user who "owns" the article you use for your homepage deletes their account and that article is deleted too because they are set as the author). No amount of coding will properly fix these types of scenarios and this is why when speaking in the context of a content management system the solution for GDPR compliance, for better or worse, needs to involve human intervention.

A system plugin (because that is the only plugin group loaded on every request) can hook everything in the system. It is all reliant on extensions dispatching events for those actions.

This means it can be done in one plugin.

I agree with @mbabker. While "allowing" users to delete their accounts on people's sites can be achieved with existing third-party extensions (e.g. https://extensions.joomla.org/extension/delete-my-account) issues may arises thereafter in relation to any content created by that user on the affected website (e.g. articles, forum posts, images uploaded, etc.). "Self-deleting" user accounts can result in management worries for site owners.

Normal TOS policies should state that "All content created by users on this site remains the property of the website" (or words similar to that effect). There is the issue about what may be construed as public vs. private information/content, however, let's not get into arguments about people who join a website, make a contribution, and then want to leave the site and have all their contributions removed at the same time. Websites can be destroyed if there's open slather on allowing people to create and remove content at their own discretion; the discretion as to what content remains the property of the website should, in my opinion, rest with the site owner and not with the author of the content. It depends on what is within the TOS defined by the site owner; Government "intervention" should not be involved.

The notion that the GDPR can impose fines of up to €1 million surely should be mitigated by the ability to prove personal damage as the result of joining a website and how information about them is collected and used. Obviously, if a site's TOS and privacy policy is written clearly, people should be know before they join a website how their "information" can be used and, for the same reason, I believe that existing methods (i.e. click to confirm acceptance of the TOS) within Joomla should suffice.

But, as we've seen written countless times, the GDPR is trying to create a catch-all for "everything" and the approach is terribly confusing. Good grief, if people have to attend a "GDPR orientation course" in order to understand the consequences then it ain't simple for us poor hobbyists, is it? Makes one wonder why anyone would create a website if there are all these arcane rules; maybe that's the intent of the GDPR: to stifle website development?

@mbabker

You're not explaining how the "rules appear to be more complex than can be solved with just a plugin".

no because you did

At least in the case of a user account, as already pointed out in this thread, it is a lot more involved than just DELETE FROM #__users WHERE id = $user.

Exactly the point I was making .... I am not disputing that. Users removing their accounts (for the reasons you have stated) requires more than just a plugin. Therefore The (gdpr) rules appear to be more complex than can be solved with just a plugin

When it comes to the actions that can be accomplished by plugins ... is it to be done with a [plugin or several plugins ?

For the third time today, if core were to offer a solution out of the box (minus the delete user thing because it's so technically impractical) it would all be in one plugin because system plugins can act on all events; as in you don't need a user plugin, and a content plugin, and a Smart Search plugin, and a (insert any other plugin type here) plugin.

@mbabker

You said in response to "Allow an Article with the gdpr to be displayed during registration ?"

        "Already possible, see ToS setting in profile plugin."

However, I thought back in December we confirmed that the ToS setting displays a link to the article, and that GDPR regulations require all the verbage to be on the registration screen.

And I am really okay with no delete user thing, I've got other stuff that goes with that, so I'll have to do it manually anyway.

-Michele
Dear God, I have a problem. It's me.

Yes the basic verbage does need to be on the screen. Details can however be on a link

My solution is.. and here my problem at the same time...:

• we can use custom fields to show in user registration form the privacy and so on.
• the problem would be just sending those information via e-mail both to the user and the admin, because there's no core functionality now to do this.

Example: I register and accept privacy custom fields and so on. But user doesn't receive copy of that and admin doesn't as well. While, when you use custom fields in a simple contact form, those fields are sent to the admin.

Just do the same thing with registration form, and send the content of the custom fields via mail, so there's a written copy of all the acceptance, with date, received by user and admin.

ps: any advice?

I have a plugin that I will soon be submitting to the core that will store the date of consent in the user_notes table

I see a relevant PR that is not mentioned here ? #19023

Thanks @brianteeman https://issues.joomla.org/tracker/joomla-cms/20051

Closed as we have a PR for testing and improvement ;) #20051