I have tested this item ? unsuccessfully on 79f39d7

Nomatter if you chose Yes or No the user note will return a succesful acceptance of the GDPR field.
Got the same message for user Yes and No in the user notes. The one below is for No
"Notes for user test2 (ID #935)
#2 Privacy Policy
Sunday, 01 April 2018 21:04

The user consented to storing their user information using the IP address
The user agent string of the user's browser was:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299
This information was automatically recorded when the user submitted their details on the web site and checked the confirm box"

@ot2sen Thanks for the quick test. I cleaned up somecode and forgot to update it everywhere. Should be ok now

@brianteeman thanks for the clean up. Now it do show the error that acceptance is required, but it does so nomatter if you chose Yes or No. Getting this nomatter the choise:
"Error
Registration failed: Agreement to the site's Privacy Policy is required."

@brianteeman
Just a question (probably a stupid one). Any way to have this plugin merged to 3.8.x? I don't know if there's any B/C breaks, and I know a patch release doesn't integrate new features, but having it in 3.9 would mean being late to the party, as the GDPR will come into effect several months before the release of 3.9.

@brianteeman When the plugin is enabled there is an issue with manually adding a user in administration. You cannot save a new user because the plugin want you to accept and there is no option for that, and shouldn´t be as you cannot accept on their behalf.

@Sandra97 that would be up to the maintainers. I asked @wilsonge but got no reply

@ot2sen grrh - thats because I fixed it on the front end

I may need some more info concerning the display of the Short Private Policy (privacy_note) as I see it nowhere. Does it mean it is only displayed in the plugin edit form?.

The user Note is saved in the language used by the UI when registering or confirming the acceptation for an already existing user. I suggest to force use a specific installed language defined by the Super User.

If that user note is deleted, it is not proposed anymore to a user login to accept the Policy as "consent" is added to the __user_profiles table.
This means that, if there is a change in the Policy (whatever it is), one would have to go over that table and delete the row for each user.

Concerning back-end, I confirm @ot2sen findings. The call to the plugin should never be done there. And it is not only a matter of accepting on their behalf, but also a wrong IP for that user.
I tested OK by adding

if ($this->app->isClient('administrator'))
		{
			return;
		}

in some methods.

IP: Here I get a Notice on localhost as the IP can't be fetched.
It is solved if I change the code to

				// Get the IP address
		if (!empty($_SERVER['HTTP_CLIENT_IP']))   //check ip from share internet
		{
			$ip = $_SERVER['HTTP_CLIENT_IP'];
		}
		elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))   //to check ip is pass from proxy
		{
			$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
		}
		else
		{
			 $ip = $_SERVER['REMOTE_ADDR'];
		}

In that case no Notice and I get this:
The user consented to storing their user information using the IP address ::1
which corresponds to last figure of my router.

@infograf768 @brianteeman please let's use the app input and not directly access the super globals:
eg: ‌‌$app->input->server->get('REMOTE_ADDR') instead of $_SERVER['HTTP_X_FORWARDED_FOR']

@dgt41 thats on my todo list ;)

@infograf768
I said in the op that the disply of the short summary was not implemented and that I was requesting some help on that
The user note should be stored in the language of the user who submitted it imho. Forcing it to an arbitrary language makes no sense to me. And see *
If there is a change in the policy you only have to, and only should, change the user profile field - not the user note. You should never delete the usernote because you must have a record of everytime that the user confirms to the policy.

• I intended to add the summary note to the usernote (but i didnt implement that yet)

Wondering why this has to be a core plugin?

@rdeutz on the basis that it can be used by almost every joomla install

And if that category has been deleted?

On Mon, 2 Apr 2018, 14:37 Quy, notifications@github.com wrote:

@Quy commented on this pull request.

In plugins/user/privacyconsent/privacyconsent.php
#20051 (comment):

•   // Get the user's ID
  

• $userId = ArrayHelper::getValue($data, 'id', 0, 'int');
  

• // Get the user's IP address
  

• $ip = $this->app->input->server->get('REMOTE_ADDR');
  

• // Get the user agent string
  

• $user_agent = $_SERVER['HTTP_USER_AGENT'];
  

• // Get the date in DB format
  

• $now = JFactory::getDate()->toSql();
  

• // Create the user note
  

• $userNote = (object) array(
  

• 	'user_id'         => $userId,
  

• 	'catid'           => 0,
  

OK don't add it as option, but default it to Uncategorised.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#20051 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8fKdLC7V4umuYjp2nRDeN3ZqF7wkks5tkimEgaJpZM4TC9Cu
.

I am still not convinced that this has to be a core plugin. What is the difference to the user profile plugin, we have a TOS field you can make a requirement and then someone can only register when agreeing? Even if this doesn't fullfil all GDPR requirements extending the user profile plugin might be a better way (from an organisational point of view).
The problem I see is that we can't add it to 3.8 within a patch release, because it is a new feature. So it has to go into 3.9, what wouldn't be a big problem. We "only" had to make what we have now as 3.9 move to 3.10. That's a lot of organisational work but that would be the way to go.

Tried the user profile plugin, you can register even if you don't agree to the TOS. Sounds stupid but that's how it is. I would consider this as a bug.

Any issue with the user profile plugin should be raised in a separate issue so I wont comment on it here.

I don't see why it would mean we have to then have a 3.10 release

Not all users are capable of creating a plugin like this (it took me a long time and its not completed) and we shouldnt be forcing people to go and pay for a plugin (the only gdpr options are commercial) for something the majority need. A vast number more people need this than need the multilingual associations ;)

Anyway I will stop commenting and fixing things. Not wasting my time if you are so against it

I don't see why it would mean we have to then have a 3.10 release

Any efforts ongoing to add tools to core to help with GDPR compliance should in theory be released before the May 25 enforcement date (this and #19023 are the two big ones I'm aware of off the top of my head). If we stop breaking SemVer that calls for a 3.9 release. For a while now, we have been advertising 3.9 would be 3.x EOL and released together with 4.0, considering 4.0's nowhere near ready and there should still be a 3.x minor at the same timeframe as 4.0, right now the best course of action is having 3.8.7 or 3.8.8 with these features and keeping 3.9 as advertised or having a 3.9 feature release and renumbering what is currently known as 3.9 as 3.10. You've already chastised me (rightfully so) because 3.8.3 and 3.8.6 technically should've released as 3.9 according to SemVer.

I forgot we were releasing 3.9 and 4.x at the same time

With a global issue like the GDPR compliance one, it would only strengthen Joomla!s reputation of being a step ahead (like with PHP7, encryption, etc.), if we target a 3.9 release early May with these user friendly GDPR features including #19023

Add some of the proposed solid features that users will find of great use:
Schedule featured articles #18052
Custom fields view on form #20039
and perhaps a few more from the new features list.

Let a 3.10 be the final one of this series with the focus of the backporting for easy adaption to 4.

Following our development strategy, if we're adding new features we are supposed to release 3.9. But we said more than once that 3.9 will be the last release of the series, to be released alongside with 4.0, so it can be confusing for users if the plan we started to promote more than one year ago is now changing.

If ever it's decided to release 3.9 in May, I would need to know that as soon as possible as we're supposed to publish an article about 3.9 next week but this article won't make sense at all if 3.9 is not the last release of the series. (and no need to mention if we release 3.9 in May, it would make my life even more miserable than usual but well, I'm used to that) ;)

I have tested this item ✅ successfully on 0563140

Works as expected

I have tested this item ? unsuccessfully on 0563140

Issues from before now solved but saw two new/other issues while testing.
Will follow up with description of those

Front and admin now works as intended.
Noticed a problem when clicking the admin top right 'Edit user' which give an error.

Another issue or inconvenience is that the user view profile in front get a text saying 'No Information Entered' for an action that is not editable.
Perhaps this should instead say when user gave consent?

@ot2sen fixed the admin edit profile form

No idea what to do abut the front end view profile. I guess the entire block should be hidden on the view profile page but dont know how.

@brianteeman error gone on admin edit profile link. It does show a new tab though now 'Web site privacy' with yes/no tick option. Will save even when no, but the tab an options probably shouldn´t be shown at all.

Another thing, or two things, is that for the user notes part the default config in com users is 5 notes and people might have changed that value. Probably they didn´t but worth noting on activating the plugin that they should pay attention to having enough "recording space set".
The other thing for user notes is that you as admin actually can edit these privacy notes, like in change date or text. Should the notes titled privacy be non-editable perhaps?

Should the notes titled privacy be non-editable perhaps?

Not unless you're going to add a flag to notes specifically marking it as a privacy related note. As this is being done as a plugin and not an integration in com_users, the component dataset shouldn't be getting plugin specific fields added to it. And we definitely shouldn't block edits based on an arbitrary string in the title.

Let me rephrase to avoid title confusion in second hand English :)
Should saved consent items be editable?

Probably not, but changing the behavior in any part of com_users is IMO out-of-scope if this is being done as a plugin, which is currently the case (because components should not be aware of a specific plugin's implementation of a feature otherwise the feature should just be integrated into the component). From an architecture perspective, this PR has gone as far as it can as a plugin. To do more things which would call for changes in the com_users data structure (such as an indicator in notes to mark it as a privacy consent related note).

Code change proposal, file: privacyconsent.php,
Replace existing code with:
Rules 107 - ... (instead of JFactory::getApplication())

$task = $this->app->input->getCmd('task'); 
$option = $this->app->input->getCmd('option');

Rules 213 - ... (instead of generic php code)

$query = $db->getQuery(true)
	->delete($db->qn('#__user_notes'))
	->where($db->qn('user_id) = ' . (int) $userId);
$db->setQuery($query);
$db->execute();

Rules 230 - .... (instead of generic php code)

$query = $db->getQuery(true)
	->delete($db->qn('#__user_profiles'))
	->where($db->qn('user_id') . ' = ' . (int) $userId);
$db->setQuery($query);
$db->execute();

I second here the opinion of @rdeutz. It should not be part of the core as it provides functionality which does not belong to a base system of a CMS. It is a very good plugin and would perfectly fit into the eco system of Joomla and should be published in JED.

@sandewt thanks - I corrected the typos and added your code

@dgt41 can you send me the modal code please

@brianteeman error gone on admin edit profile link. It does show a new tab though now 'Web site privacy' with yes/no tick option. Will save even when no, but the tab an options probably shouldn´t be shown at all.

It should show for your own profile so that is correct. I will check on the validation

@ot2sen fixed the validation issue

@ot2sen the privacy fields are no longer displayed in the view profile page as there is no value to them being displayed here

End-user here reading this with interest. Thank you @brianteeman et al for this invaluable work; it looks to be exactly what is needed for GDPR compliance. I'm sure that end-users would want this ASAP and in time for 25th May in the UK by whatever means it can be released, be that by JED download or by Joomla Update as v3.8.7 (yes, I understand the issue about new features) or v3.9.0 with 3.9.0 being refactored as 3.10.0. Wee will spread the word in the Forums, Twitter etc. I suspect that most users are not aware that 3.9.0 is supposed to be EoL for 3.x series; those are aware will be easy to reach.

I have tested this item ? unsuccessfully on 3f8ac61

Former issues solved. Backend edit user via top right now behave correct on yes/no. Frontend profile view now exclude the privacy group.

New issue found: When clicking Edit on front user profile it return an error 1054

Adding screenshot with more detail of the error

That bug comes from
if (!in_array($name, array('com_admin.profile', 'com_users.profile', 'com_users.registration')) || $layout != "edit" && $view != "registration")

But I will need some help to fix that

But I will need some help to fix that

File: privacy.php, rules 84 -

->select($db->quotename(array('id, alias, catid, language')))

Should be

->select($db->quoteName(array('id', 'alias', 'catid', 'language')))

Option: quoteName or qn (to be consistent)
Beware: quotename is not correct (change in rules 84 - 85 - 86)
Note: see also comment(s)

When adding/saving a user under Users > Manage:
PHP Notice: Undefined index: privacyconsent in \plugins\user\privacyconsent\privacyconsent.php on line 111

When editing admin account in the drop down in the upper right corner under Edit Account:
Save failed with the following error: Agreement to the site's Privacy Policy is required.

1. I cant confirm
2. yes thats correct if you dont agree. When you change your own personal information you have to agree every time

File: privacyconsent.php

Proposal, to be consistent, to replace existing code in:

Rules 272 -

$query = $db->getQuery(true)
	->select('1')
	->from($db->quoteName('#__user_profiles'))
	->where($db->quoteName('user_id') . ' = ' . (int) $userId)
	->where($db->quoteName('profile_key') . ' = ' . $db->quote('consent'));
$db->setQuery($query);

qn becomes quoteName
q becomes quote

File: privacyconsent.php

Hi, possible you can do something with this:

Note 1)

Rule 72-

$layout = $this->app->input->get('layout', 'default');
$view	= $this->app->input->get('view', 'default');

Why not this way? More secure.

$layout = $this->app->input->getCmd('layout', 'default');
$view	= $this->app->input->getCmd('view', 'default');

Note 2)

catch (Exception $e)

{

Rule 182 is empty.

Note 3)

Rule 84

$fields = array(
	'privacy',
); 

$fields may not be used ?

@sandewt thanks for these. If you could submit them as a pr on my branch it will make things easier for both of us
https://github.com/brianteeman/joomla-cms/tree/privacy

PS still need to find a way to display the short message above the checkbox

@brianteeman,

This is indeed not the way. I am not sufficiently familiar with the possibilities of Github.

@sandewt Go to my branch - ,link above
Find the file you want to edit
click on the pencil icon - top right of the code box
this will make a fork of my repo
make your changes to the file
when you save then it will be submitted as a change to my pr for me to approve

Check the PHP error log. When adding/editing a user in the backend, there is no privacyconsent radio buttons in the form.
PHP Notice: Undefined index: privacyconsent in \plugins\user\privacyconsent\privacyconsent.php on line 111

Markup in tooltip and styling.

@Quy assuming that was the edit profile link in the admin - then I cant confirm

@Quy found the error in the logs as you described - pull requests to fix it are welcome

when you save then it will be submitted as a change to my pr for me to approve

@brianteeman

I have kept the schedule and this results in a new branche (patch-5) and make some changes.
Is that what you mean? Or should I make a New pull request of that branche yet?

this might explain it better https://help.github.com/articles/editing-files-in-another-user-s-repository/

privacyconsent needs to be added to the $data array. I don't how/where in order to submit a PR. ?

When an Admin adds a user, should (the text of) the notification email contain something about the gdpr ?

When an Admin adds a user, should (the text of) the notification email contain something about the gdpr ?

Not possible in the current plugin driven approach. Email sending doesn't have event hooks, and plugin logic shouldn't be hardcoded into components (go back to #20051 (comment) and #20051 (comment) for the technical explanation on that; part of it is we shouldn't do something with core plugins that the external ecosystem cannot either, so we shouldn't hardcode plugin attributes into a component if the ecosystem is not allowed to core hack to do the same).

possible or not it does not matter.

As stated in the original post

Any existing user who tries to login will be redirected to the edit profile page so that they can consent before continuing.

@mbabker

Not possible in the current plugin driven approach. Email sending doesn't have event hooks,

But when a user is added in the backend a notification email is sent to the email address of the created account is it not ? "_You have been added as a User to Weblinksonline by an Administrator.

This email has your username and password to log in to_"

It is that to which I am refering

Let me explain a little better.

The process of sending an email doesn't have any event hooks. So a plugin cannot hook any code calling Joomla\CMS\Mail\Mail::Send() because our Mail class and the parent PHPMailer class do not have event dispatching/hooks in them.

The email you're talking about is sent by the "User - Joomla" plugin during the onUserAfterSave event dispatched by our MVC classes. Even though a plugin is sending the message, the plugin can't be hooked by this privacy policy plugin to modify the email text.

@mbabker
Yes I understand but I was not asking for the plugin to alter the text.

The email you're talking about is sent by the "User - Joomla" plugin during the onUserAfterSave event dispatched by our MVC classes.

Yes that email. I am suggesting the Value for "PLG_USER_JOOMLA_NEW_USER_EMAIL_BODY" be edited. So that when a new user is added via /administration ... the email that the user receives states that the GDPR has been agreed to. (Whether the agreement was made by requesting admin to add them or for whatever reason.

e.g.
in \administrator\language\en-GB\en-GB.plg_user_joomla.ini
"Hello %s,\n\n\nYou have been added as a User to %s by an Administrator.\n\nThis email has your username and password to log in to %s\n\nUsername: %s\nPassword: %s\n\n\nPlease do not respond to this message as it is automatically generated and is for information purposes only."
becomes something like
"Hello %s,\n\n\nYou have been added as a User to %s by an Administrator.\n\nThis email has your username and password to log in to %s\n\nUsername: %s\nPassword: %s\n\nBy logging into your account you are agreeing to the GDPR.\n\nPlease do not respond to this message as it is automatically generated and is for information purposes only."

Architecturally this change cannot be made as it therefore hardcodes references to the privacy plugin into the "User - Joomla" plugin. As far as workflow goes if someone wants to use language overrides to add that text to their site's new user email that is entirely up to them, but from a code perspective it would be improper practice to create a hardcoded reference between plugins (because again, extensions can't modify other plugins to include their references in this way, and plugins are designed to be pluggable behaviors that the other parts of the system shouldn't be hardcoded to reference; if someone wants to have a custom privacy policy plugin and disable this one changing the email text shouldn't be hardcoded to only do so based on one plugin being installed/active).

Forget about it being architecturally wrong it is wrong from a legal requirement. The user must consent themselves. You cannot consent for them.

As I have already said and as is written in the original post

Any existing user who tries to login will be redirected to the edit profile page so that they can consent before continuing.

Please stop derailing this with your feature requests for something that you have been told is

1. Technically not possible
2. Legally not compliant

@brianteeman

Please stop accusing me of bad intentions. You are constantly on my back. If my suggestions are wrong then they are wrong but there is certainly no intention to derail this. Despite your constant wragging I will not rise to it and simple be polite and say I hope you had a good Easter.

Does this also consider users who do not login? Consent is required to store session cookies with unique identifiers (such as a session ID); these are as far as I know are still stored by default in Joomla even for unauthenticated users (and the option to store this data based on "legitimate interests" I suppose does not apply because this should not be necessary to achieve the goal of reading a web page). To me this is much more important than the registered users (which might be a limited set of employees).

As far as I could tell the default text also does not:

• Say which personal information is stored (which I think would be reasonable to have in the default text since the Joomla operator probably does not know this).
• How the information is to be used (could enumerate at least how Joomla uses the information; if the operator has additional uses they could be added manually).
• How long the data will be stored (I suppose it could use a placeholder).
• Who will use the data (I suppose it could use a placeholder).
• Tell users how they can withdraw the consent (must be simpler than agreeing; perhaps needs a button to "logout" an unregistered user in order to clear his session cookie). This is a mandatory item for GDPR consent.

Neither does it seem to store which version of this information was consented to (if the policy changes, you need new consent).

If http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm has any value in the context of GDPR then a session cookie falls under the category of being exempt as it acts as an authentication cookie (even an unauthenticated user, because to be able to submit forms a valid token must be included in a request and the submitted token is validated against the session).

It is impossible to run Joomla in a way where a session cookie is not created or persisted beyond one request, just to find out whether the person visiting the page is a guest or previously authenticated requires a read action to the session data store, and a session must be started to read this data.

all valid point about what a policy might need to say for a site. No single policy will ever suit all sites which is why they are user editable.

also session cookies are disposable temporary items and not stored data

Note: The EU cookie law is 7 years old, and the GDPR supplements it...

If http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm has any value in the context of GDPR then a session cookie falls under the category of being exempt as it acts as an authentication cookie (even an unauthenticated user, because to be able to submit forms a valid token must be included in a request and the submitted token is validated against the session).

Yes, but this is not what is usually done in Joomla. And even if it was done, there is no reason why the cookie could not be created once submitting the first form (although I believe this would require bigger changes than a plugin could provide). In the GDPR you can avoid consent only if what you are doing (using a session cookie for example) has no better alternative. If you don't have to create a session cookie, you must not create one (or you must get consent).

It is impossible to run Joomla in a way where a session cookie is not created or persisted beyond one request, just to find out whether the person visiting the page is a guest or previously authenticated requires a read action to the session data store, and a session must be started to read this data.

Currently; but failure to modify the software to follow the law is not really a good defense. All cookies are sent on every HTTP request so it is trivial to read if the user has an open session.

also session cookies are disposable temporary items and not stored data

The EU disagrees. Any data is considered (the law does not mention cookies except in the supplementary information). And session cookies last for months for many users who do not close their browser anyway...

For authenticated users, I believe the current approach would suffice. But starting a session cookie when not strictly required is something that in the cookie law would be allowed if you showed a popup (user didn't even need to click OK), but starting with the GDPR requires consent if it stores any personal data (which may be a session-id if the server stored any IP address or similar together with it).

https://gdpr-info.eu/recitals/no-30/

under the GDPR, any cookie or other identifier, uniquely attributed to a device and therefore capable of identifying an individual, or treating them as unique even without identifying them, is personal data.

So if the session in Joomla is guaranteed to not store any IP address or other information that could be used to identify a natural person or track the browsing habits of this session, a cookie popup + a cookie policy on the page should suffice. (But as far as I know, this is not the case)

@sjoelund

A point to note that when the cookie law first came out the ICO site dropped a cookie on the visiting computer. After it was brought to their attention their devs altered the way their site worked.

@sjoelund those are your opinions which I dont happen to share for one very simple reason. Every time you visit my web site i get your ip address in the web server logs. So irrespective of any cookie I am logging your ip address anyway. Without a solution to that, whch is the fundamental way that the web works, then as far as I am concerned your opinion can never be correct or possible.

In addition as you appear to have misquoted or selectively quoted https://gdpr-info.eu/recitals/no-30/ is NOT an official web site and the full text says

1Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. 2This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

Yes, but this is not what is usually done in Joomla. And even if it was done, there is no reason why the cookie could not be created once submitting the first form (although I believe this would require bigger changes than a plugin could provide).

No, you couldn't. Submitting a form in Joomla (which would include the acknowledgement button on any type of cookie consent popup) requires a valid CSRF validation token, this token can only be validated against an active session, therefore not having a valid session (the cookie being part of that) would prohibit the user from even accepting whatever cookie prompt a site has without removing said CSRF validation process, and it is a basic security practice that any user form submission has a CSRF validation to ensure it came from a valid user session.

In the GDPR you can avoid consent only if what you are doing (using a session cookie for example) has no better alternative. If you don't have to create a session cookie, you must not create one (or you must get consent).

The session cookie is an authentication cookie only transmitting whether the user has an active session and if so the information required (usually the session identifier) to link that cookie to a session, which is then validated to ensure the correct device/cookie is associated with an active and valid session. Nothing more, nothing less.

Currently; but failure to modify the software to follow the law is not really a good defense. All cookies are sent on every HTTP request so it is trivial to read if the user has an open session.

Again, even if the cookies are read to determine if there is a valid session, if one is not started and a cookie sent as part of the response, this prohibits the user from being able to perform any action which has CSRF validation because there is no session in place to make such a validation against. Without a flashing red button saying "START A SESSION" a user would never be able to perform such a basic action as logging into the website.

The cookie is stored on your computer so the thing you woulld be concerned about is the data in the session table. A simple example of the contents of that table for an unauthenticated user would be as follows and there is NO personally identifiable information in there
O:24:"Joomla\Registry\Registry":3:{s:7:"*data";O:8:"stdClass":1:{s:9:"__default";O:8:"stdClass":3:{s:7:"session";O:8:"stdClass":2:{s:7:"counter";i:1;s:5:"timer";O:8:"stdClass":3:{s:5:"start";i:1523084671;s:4:"last";i:1523084671;s:3:"now";i:1523084671;}}s:8:"registry";O:24:"Joomla\Registry\Registry":3:{s:7:"*data";O:8:"stdClass":0:{}s:14:"*initialized";b:0;s:9:"separator";s:1:".";}s:4:"user";O:20:"Joomla\CMS\User\User":1:{s:2:"id";i:0;}}}s:14:"*initialized";b:0;s:9:"separator";s:1:".";}

Wherever possible the setting of cookies should be delayed until users have had the opportunity to understand what cookies are being used and make their choice. Where this is not possible at present websites should be able to demonstrate that they are doing as much as possible to reduce the amount of time before the user receives information about cookies and is provided with options. A key point here is ensuring that the information you provide is not just clear and comprehensive but also readily available.

https://ico.org.uk/media/for-organisations/documents/1545/cookies_guidance.pdf

Seems pretty clear that setting a session cookie as soon as the site is visited is acceptable (by the ICO) provided it is made clear as soon as possible.

@wilsonge @rdeutz the deadline is approaching - if this is never going to be accepted then I will close it and stop wasting peoples time with it.

If this is going in core it needs to go in next release after 3.8.7, otherwise either make it standalone (ala weblinks/IFW) or shut it down and leave it to third party to address the problem. Either way this needs to be priority. /me goes back to being worker bee

Would be logic to be proactive and have a 3.8.8 or 3.10 with this high value feature for a large part of the user base released in the next weeks. Not often that a small size feature will have such large reach and be so useful globally. Let us show the way. Marketing probably wouldn´t mind either to have such a hot topic to spread the good word about Joomla!

can we first test it ? i mean at least the basic usage ?
from a quick test
it works for new users,
but not for existing users, when logging with an existing user you are correctly redirected to the edit profile but whatever you fill in the radio button .... you got

maybe already reported
#20051 (comment)

p.s
@brianteeman

agree or disagree i don't care

ROTFL ?

We can and have unsuccessfully multiple times during the proces of getting things right. Guess what you see is the two known issues that need fixes before it can have the needed successful tests.
Helps to solve those known issues where requested. I will test again when ready :)

Forgive me for my elephant way to re-focus

Il mar 10 apr 2018, 21:25 Ole Bang Ottosen notifications@github.com ha
scritto:

We can and have unsuccessfully multiple times during the proces of getting
things right. Guess what you see is the two known issues that need fixes
before it can have the needed successful tests.
Helps to solve those known issues where requested. I will test again when
ready :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#20051 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALFsdvA3WtLh-nNCnk2kuDRbRbHhvSeks5tnQcVgaJpZM4TC9Cu
.

Closed - I have no wish to proceed further with this

Can I persuade you otherwise? I'd really like to see this get merged and do a 3.9 release with just this in on top of the existing 3.8 release.

@wilsonge you are alive? As you never replied to anything and other maintainers said no way then I wasnt prepared to waste anymore time and energy

Take the hand that is reached out Brian :)
Excellent message from George, go go, make it happen. Ready to test when the last fixes are in.

yes, please reopen

i am still waiting for help as requested on the op and in the comments for the things i cant do. complete silence on them :(

Ok, let us do a shout for those items. Please re-open so people can see it matters to share their skills to an open PR, thanks. :)

i cannot guarantee to you that i'll come out to you with the right fix for the 2 mentioned issues, i'm not so confident withjform,
but let's give us another chance,
the pr concept goes in the right way, imho,
...so common let's try it again..

@brianteeman check: brianteeman#71

@alikon the issue you found is a relatively new one - that was definitely working before. I am guessing that one of the improvements suggested has broken it

@dgrammatiko please let me know when you have finished with your patch. Each time I look at it to comment its not quite correct you update it ;)

it should be ok now

@dgrammatiko had to revert your code as it didnt work at all. When you have a pr that you have tested then please let me know. Otherwise this will have to stay as is - just the same as the modal in the userprofile plugin

Getting late in Europe now. Brian perhaps you could sum up the missing bits? For other to promote while you sleep well across the pond :)
There is the modul part that Dimitri is fixing, and the @Quy part that @alikon is looking into already.
Last part must be the notes from @sandewt that was manually suggested here but trouble with PR to your branch. Anything else? Almost lost track of the 140 comments.

my quick&dirty fix brianteeman#72

Testing in Joomla! 3.8.7-dev Development:

After installing the patch and adding the code of @alikon, the following:

When you have given an agree, the field will reappear after Edit profile. See the image

This problem can be solved with the following code: $form->removeField('privacy', 'privacyconsent');

The tooltip does not display the text correctly.

shouldn't be tested on 3.9 branch?

This problem can be solved with the following code: $form->removeField('privacy', 'privacyconsent');

can you tell where exactly ?

shouldn't be tested on 3.9 branch?

There are more problems.

can you tell where exactly ?

See brianteeman#72

@sandewt thank's added your fix to brianteeman#72

@alikon / @brianteeman

At first this seemed to be a solution, but the problem is only being moved. Sad.

But when you (re) save (Edit Your Profile) the $form variable is emptied, after which the known warning message appears.

can you recheck please i've made some more changes, and shouldn't occur now...

@alikon, smart solution.

I did the recheck and it works. Nice.

An agree is saved in the database in the column profile_key as consent.
Why not as profile.consent or profile.privacy in accordance with the other fields?

Thank you @alikon @sandewt @zero-24

tweaked it a little on the admin profile so that the group as well as the field are removed if already consented in the admin profile screen

From my perspective all the bugs have now been resolved.

The only request outstanding was to change the modal code by @dgrammatiko which can be done if working code is submitted although it should be pointed out that the same modal code is used in the userprofile plugin so maybe they can both be changed in their own pr

I have tested this item ✅ successfully on e550c08

Former issues solved. Works well. Thanks Brian and contributors.

Note: Not sure if the modal issue to fix later also cover that visual HTML break when you hover the front Privacy Policy link. Probably just a text string change needed there

@ot2sen i cant replicate that issue

@brianteeman Did a fresh uninstall/add patch/discover/install, and still seing white bg box with the br inside.
Same as seen in #20051 (comment)
and screenshot here:

@ot2sen me neither

I have tested this item ✅ successfully on e550c08

@brianteeman @alikon those shots of yours are from the registration page, right?
There I too see a black box white text and two lines.
The issue with white box black text and br shown in one line is when a user is registered (created by an admin for example) and do log in in front and directed to their profile.

The tooltip does not display the text correctly.

I find a different result by testing between Joomla! 3.8.7-dev and Joomla! 3.9.0-dev

Joomla! 3.8.7-dev
page User Registration
link: Privacy Policy -> tooltip OK
link: Terms of Service -> tooltip OK

page Edit Your Profile
link: Privacy Policy -> tooltip NOK

Joomla! 3.9.0-dev
page User Registration
link: Privacy Policy -> tooltip NOK
link: Terms of Service -> tooltip NOK

page Edit Your Profile
link: Privacy Policy -> tooltip NOK

[EDIT] Related #20177

boohh some magic github behaviour ? i don't know

the same modal code is used in the userprofile plugin so maybe they can both be changed in their own pr

Lets merge this and create an issue to move the modals to BS. Fair?

I can see what the problem is - it is not related to this PR - looking to see if I can fix it

Fixed the tooltip issue in #20177 as it is unrelated to this PR

@dgrammatiko it was you that wanted the modal to be fixed not me ;)

@brianteeman Thanks Brian. It 20177 did solve the issue for the edit part. Unrelated to here I see, but now show correct in testing this too

@brianteeman

There are still a few things to be solved.

Every time a user edit their profile [Edit Your Profile], a user note [User Notes] is saved again. *

Moreover, I still miss the Category and the Revieuw Date.

See the image.

[EDIT] concerning the Privacy Policy

The user note is part of the changes that you and alikon made. As explained my intent was a user would re-confirm every time they edited the profile but you guys removed that just didnt do it completely

Review note is not set because there is no need to. It is not set on a note by default when created in the ui either

Category has already been explained and cannot be changed

?
i'll fix the users note saved again issue, if not someonelse do it in the meantime...

This is my plugin https://github.com/JoomlaZen/plg_system_personaldata for a similar problem.

In addition to being able to write down your text for each language, it also adds an opportunity to include an interesting feature.

While the checkbox is not checked to submit button add disabled attribute

This plugin already supports the ability to display a link to a privacy policy in any language. You link to one article and if that article has an associated translation then that will be displayed instead of the linked one

Disabling the button is nice but not really needed as it is a required field

@brianteeman

Disabling the button is nice but not really needed as it is a required field

You can add this to the settings

In Russia they demand that such consent be maximally informed. And if the shape of the button is not active it adds an extra reason to think about.

In addition, such an agreement would be nice to add to the feedback form in com_contact. Because there is also confidential information there

Personally, I like the checkbox more than radio

In my implementation, I made my layout for the type of field. To enable developers to override it

But all this is only my vision, in general, I really like this PR at the moment it is a very important function

As explained my intent was a user would re-confirm every time they edited the profile

@brianteeman

I can partly support your reasoning.

So, why not offer a choice for both options?

It should be one or the other - we have enough options in joomla already ;)

@sandewt please confirm that

Every time a user edit their profile [Edit Your Profile], a user note [User Notes] is saved again. *

has been solved by brianteeman#75

@alikon With latest fix there is no longer added a new user note when user edit profile. Works :)

It should be one or the other - we have enough options in joomla already ;)

@brianteeman

I am not a true expert on the GDPR. But my cautious interpretation for the preferred operation of the plugin is as follows. I hope that I will be improved if it is not.

At registration / after logging in for the first time, the user must agree to the GDPR.

At the moment that (radical) changes take place in the processing activities, the user should give permission again.

This means that the current two (proposed) options are actually a compromise, each with their advantages and disadvantages.
In fact, the choice depends on the nature and weight of the personal data processed. And the user-friendliness

Note:
The TOS does not ask for permission every time.

[EDIT]

Every time a user edit their profile [Edit Your Profile], a user note [User Notes] is saved again. *

Thanks @alikon, I can confirm, it works.

Note file privacyconsent.php rule 102, $field is nut used, required?

$fields = array(
'privacy',
);

marketing and documentation copy is in progress and should be ready to review this weekend

Great thing!

will it become a Joomla standard plugin with one of the next versions or do I always have to install it separately?

Even if the contact form does not store any data, these are processed by the provider (an e-mail is generated from the entries), that is to say the processing of personal data, therefore I think that a checkbox with the corresponding notice is necessary and required according to the DSGVO.

@The-Web-Designer If that was true then you would need consent before you send me an email

At the moment that (radical) changes take place in the processing activities, the user should give permission again.

This is what I would like to propose. See the image.
The change date (time) is set by using the calendar.
The changes are tracked in #__user_notes in the created_time and then in the modified_time columns.

[EDIT] A new wish is to integrate this all into the Terms of Service (TOS).

Not in favour of adding this

On 19 Apr 2018 3:30 pm, "jsanders" notifications@github.com wrote:

At the moment that (radical) changes take place in the processing
activities, the user should give permission again.

This is what I would like to propose. See the image.
The change date (time) is set by using the calendar.
The changes are tracked in #__user_notes in the 'created_time' and then
in the modified_time column.

[image: screen shot 2018-04-19 at 14 29 10]
https://camo.githubusercontent.com/20eca0a5a3546bd7c09d35ac4defce3111181194/68747470733a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f32653432336364663630396534346365346132333238343864643331646664392e706e67

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/tracker/
joomla-cms/20051.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#20051 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8TKYLsJq-lhF0EsVS9DfGgOBS7tBks5tqJ-hgaJpZM4TC9Cu
.

Not in favour of adding this

Oops, ....

Has everything in it.

Arguments:

1. Time backwards: first time agreement

2. Time ahead: an agreement every time

3. Time on change date: first time + only from then on an agreement

Reasonably simple code to build.

i dont believe that would be simple to use or that it is required

i dont believe that would be simple to use or that it is required

The situation may change, so it may be necessary to request permission again.

I have written some code, test and convince yourself.

https://github.com/sandewt/plg_user_privacyconsent_test02

[EDIT] Several changes code

Related to #20140

Not related at all.

Not related at all.

Clear.

A new wish is to integrate this all into the Terms of Service (TOS).

@brianteeman what do you think of that?

No. A privacy statement must not be part of the terms of service

A new wish is to integrate this all into the Terms of Service (TOS).

I see (currently) (internet) companies do that, possibly motivated by practical considerations.

As promised the documentation is prepared
https://docs.google.com/document/d/1IuQ7OMZeUOsCESfNqnPCCWmFgeG-7pixDHRLv1XiMEQ/edit?usp=sharing

Thanks @brianteeman the doccumentation works well and to the point. Added two minor suggestions.

thanks @ot2sen - i merged your changes

I have tested this item ✅ successfully on e550c08

Ready to Commit after two successful tests.

Not sure this can go RTC.
I explain:

1. Once plugin is enabled and a user logs in, the user is indeed presented with her/his edit profile page displaying the redirect message, but the already logged in user is able to totally ignore that page and switch to any other page on the site without agreeing to the Policy. This defeats imho the purpose of this Redirect as it only prevents the user from modifying her/his profile.

2. Another aspect that bothers me is the lack of even the slightest hint concerning the customization of the Short Privacy Policy and Redirect Message language strings when the site uses more than one language. Most users never go to Docs as repeatedly explained here along the years.
   The simple solution is to add a spacer/label before these fields stating which string should be overriden to customize the messages.

3. Concerning these fields, we also have a small glitch: one should not be able to enter a single space in these fields as otherwise we would get this
   
   Needs to trim
   $privacynote = trim($this->params->get('privacy_note'));

Status back on "Pending".

I accept defeat and realise this will never be merged.

Clearly I made a mistake in providing documentation for an undocumented hidden feature used throughout core

At least we can point to PRs like this and be like "we tried" when people ask why there are essentially zero tools in core related to privacy related laws such as GDPR.

Another aspect that bothers me is the lack of even the slightest hint concerning the customization of the Short Privacy Policy and Redirect Message language strings when the site uses more than one language. Most users never go to Docs as repeatedly explained here along the years.
The simple solution is to add a spacer/label before these fields stating which string should be overriden to customize the messages.

The UI is not the platform documentation. If we have to document everything in the UI then we should stop wasting our efforts and shut down the documentation wiki and all related resources (auto-generated API docs, support for that help button in the toolbar, etc.). So no, every feature does not have to have a 500-word essay as a tooltip in the interface holding the user's hand on how to do all the things.

i'm too naive telling, merge this as is, and then pr's are welcome as usual to fix the things left outside ?

and I had a terms and conditions plugin to submit as well that works the same but unlike the one in the user profile plugin doesnt require 25 clicks to setup

If it works as expected and the other things are not directly related then why not merge ?

Still seems RTC and to merge from here.
The 3 provided concerns are cosmetic.

1. User will at some point need to login and be forced to accept.
2. The provided documentation is very clear on how to use multiple languages and which strings to override for a language. Wold be logic this docs are added to Help so users/site admin will easily see it when clicking the already available Help button at the plugin edit page.
3. Can be adjusted afterwards. No site admin configuring this plugin would add a blank, but to be on the safe side then adjust with a new PR when merged.

User will at some point need to login and be forced to accept.

Valid issue, IMO should be addressed before merging this. Because fixing it is going to require moving this plugin to the system plugin group so that it can make a redirect on any HTML producing request (it'll need to hook something like onAfterRoute to do a check similar to the force reset password check, user plugins aren't imported arbitrarily like system plugins are).

Wold be logic this docs are added to Help so users/site admin will easily see it when clicking the already available Help button at the plugin edit page.

Make sure whomever is working on help screens in docs wiki gets that memo ?

@ot2sen @Webdongle @alikon its not going to happen. they are just inventing new reasons why it wont get merged and @wilsonge is completely absent despite his previous comments.

I am not investing any more time in this

User will at some point need to login and be forced to accept.

As I said, and please test before writing untrue statements, one can login forever without accepting.
Btw, I can’t care less if my comments are not listened to, they are just the results of my tests.

Can see I misunderstood your point 1. Michael is right, this is a real issue.
It is possible to move on from the profile page without accepting simply by using a menu.

it cannot be resolved with a userplugin. if you look at the password reset code you will see it is in the controllers, models, views etc.. It could be resolved with some simple javascript that I could write but I am not wasting my time.

Because fixing it is going to require moving this plugin to the system plugin group so that it can make a redirect on any HTML producing request (it'll need to hook something like onAfterRoute to do a check similar to the force reset password check, user plugins aren't imported arbitrarily like system plugins are

A possible contribution to a solution; make a system plugin and add some code like this to the file privacyconsent.php.
The user is forced to agree.

public function onAfterRoute()
{
	// Run this in frontend only
	if ($this->app->isClient('administrator'))
	{
		return;
	}

	$userId = Factory::getUser()->id;

	if ($userId > 0)
	{
		$consented = $this->loadUserData($userId); // true if consented

		$option = $this->app->input->getCmd('option');
		$task   = $this->app->input->get('task', 'default', 'string');

		// Check for consented is true
		if ($consented == false)
		{
			// Avoid infinite loop
			if ($option == 'com_users' || $task == 'logout')
			{
				return;
			}

			// Redirect to com_users profile edit
			$this->app->enqueueMessage($this->getRedirectMessage(), 'notice');
			$link = 'index.php?option=com_users&view=profile&layout=edit';
			$this->app->redirect(\JRoute::_($link, false));
		}
	}
}

[EDIT] Some changes code + text: 2 - 3 May.

GDPR party has moved at #20281 ?

@alikon a new chance ?

there is no llink to the privacy article