Massive thanks to @mbabker @joomdonation @alikon who worked on this to make it happen. As you can see it is far more than was originally envisioned.

I need an advise, please. How can we test this pr?
New installation? https://github.com/joomla-projects/privacy-framework/archive/dev/privacy.zip

Yes for now best advice is to install fresh from the dev branch. If needed I can create installable packages for use in the update component as well (but that'll have to wait until I'm not at the office since I don't have my work system set up in a way to create Joomla release packages).

Thanks! No hurry!

I'm testing this from DevBranch too, would be good to get an installable package for use in the update component as well, so I could test in a copy of a live 3.8 site.
So far looking good, thanks @mbabker @joomdonation @alikon

So far looking good, thanks @mbabker @joomdonation @alikon

Not sure if it's needed but I want to make it clear that there are others participated on this development process:

• @brianteeman did no mention himself. However, he did spent large amount of time for coding (in at least 2 plugins in this package), correcting language items, testing, merging PRs...
• @zero-24 also worked on at least one plugin.
• Other users @ot2sen, @manojLondhe, @sandewt help with testing and feedback during the development.
• Others users discussed on issues https://github.com/joomla-projects/privacy-framework/issues and suggested solutions.....

Added URL for release packages to the main issue description, I have a CI job hooked up to rebuild those on changes to the dev branch.

Thanks for that @mbabker

It comes from the 1st write gsoc2016

Il lun 25 giu 2018, 10:11 Brian Teeman notifications@github.com ha
scritto:

@brianteeman commented on this pull request.

In administrator/components/com_actionlogs/actionlogs.php
#20800 (comment):

@@ -0,0 +1,19 @@
+<?php
+/**

• • @Package Joomla.Administrator
• • @subpackage com_actionlogs
• • @copyright Copyright (C) 2005 - 2016 Open Source Matters, Inc. All rights reserved.

I dont remember if the bump script is part of the release build process.
If not then this needs to be changed here to 2018

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

At least the sampledata_testing.sql is missing the privacy frontend views.

At least the sampledata_testing.sql is missing the privacy frontend views.

That is never shipped

Once merged we should add it to https://github.com/joomla-extensions/testing-sample-data but I don't see the point in updating the SQL dump given we're moving to plugins for that (the changes we did make are for the assets table and new backend modules).

Yes, but we should have our testing sampledata up-to-date to make testing easier. Also, we should have this feature setup in some way to display how people are supposed to use it in our sampledata. I know that we can't and don't want to provide people with a perceived complete GDPR setup, because this unfortunately is a very site-specific thing, but I would expect at least one sampledata (actually I expect this from all our sampledata) to contain this.

The testing sample data has been out of date for years

Sorry for spamming with criticism here. It is a very large PR and I'm trying to post my findings as soon as I stumble upon them as to not forget anything. In general I am very much in favour of these changes and on my first glance everything looks pretty good. Thank you all for your hard work on this! Back to reviewing. ?

So far I don't see anything regarding cookie consent in this PR. My personal opinion is, that Joomla is not using tracking cookies and thus does not need to ask for cookie consent, but when we are talking about a big leap in privacy support like in this PR, I know that there will be questions about cookie consent... What are your thoughts on this?

Yes, but we should have our testing sampledata up-to-date to make testing easier.

I've got no issue updating the plugin when this work is done. I just would rather not try to update the testing data SQL dumps because that's going to be a lot of effort with minimal gain (probably means a new article explaining the feature like other features have, which means a new asset, and probably a menu item for that article, plus menu items for the frontend forms, and if we have info on admin features that means adding the admin modules to that...). Most of those changes are in tables with nested sets. Whereas updating the plugin makes use of the PHP API and is a more sane thing to attempt and maintain going forward. Plus, as pointed out, the testing data set is no longer in tagged releases. So as far as I'm concerned, lets leave the SQL dumps to the minimum changes needed to not break anything if someone installs sample data and put the bigger effort into the modern sample data structures.

So far I don't see anything regarding cookie consent in this PR.

Out of scope for what we're doing right now. If someone wants to propose something, feel free, but right now I don't think this major feature is something we need to add to Joomla core.

I enabled IP logging in com_actionlogs and I've been working on my local machine. Instead of logging ::1 it just logged 1. It seems as if the sanitization for IPs is not IPv6 compatible.

I tested on a current checkout of 3.9-dev with this PR merged in.

Issues in User Actions Log

• IP address sanitization is not IPv6 compatible
• Timestamp is always displayed as UTC. I would expect that timestamp to be in the users/sites timezone, maybe with a tooltip with the UTC time
• Timestamps are not formatted in users language
• Edits to Global Configuration are not logged
• The filename of the CSV export has UTC time, which I can understand why, but then we should add UTC in front of it.
• Some of the CSV log messages are translated, others not. None translated messages in CSV:
  • PLG_ACTIONLOG_JOOMLA_USER_LOGGED_IN
  • PLG_ACTIONLOG_JOOMLA_COMPONENT_CONFIG_UPDATED
  • User admin published the PLG_ACTIONLOG_JOOMLA_TYPE_PLUGIN plg_content_confirmconsent
  • User admin added new PLG_ACTIONLOG_JOOMLA_TYPE_MENU_ITEM Privacy request
  • User admin updated the PLG_ACTIONLOG_JOOMLA_TYPE_USER Super User
• I wrote: "When using the date in the exports, the date format should include the timezone (UTC)" However a quick Google search seems to suggest that Excel does not really support timezones, so it seems that it doesn't matter.
• MAJOR: I tried logging into the frontend and got the message that my security token wasn't valid (session timed out), but I was still logged in. The login was not logged in the actionlog.
• Should anonymous actions be logged, too? Specifically sending a request via the com_contact form.
• Registering an account and activating it is not logged

I was confused about the logging. I expected a plugin per component to log the data or each component to be augmented with the logging. Just one plugin for all core components feels strange. Also, we have messages when certain plugins are not enabled. Should we add a message when not actionlog plugin is enabled? Also I was expecting the list of loggable extensions to only list those that a plugin was active for or something. I guess what I'm having a problem with is, that there are several things that you can do to create the impression that you are logging, but you aren't, mainly disabling that logging plugin or disabling loggable extensions in the global config.

Issues in Privacy

• If you fail to assign a user when creating a request in the backend, you can not edit this afterwards. I understand that this most likely isn't possible for auditing reasons, but maybe we should add a prominent note?
• Stored consents are stored as plaintext english. Should this be translateable?
• Times in this component are nicely formatted, but I'd say we need the exact timestamp at least as a tooltip.
• Component configuration: Allow urgent requests down to day 1, not just after 10 days.
• Consent to terms&conditions is not stored
• What is the use for the Privacy Extend Consent menu item?

I think I tested everything now. If the above things are discussed/fixed/changed, I personally can mark this as a successfull test. However, testing this took me about 4 hours and so for the future I would advocate for smaller but more PRs... ?

Timestamp is always displayed as UTC. I would expect that timestamp to be in the users/sites timezone, maybe with a tooltip with the UTC time

Which one - user or site - they are not the same

Times in this component are nicely formatted, but I'd say we need the exact timestamp at least as a tooltip.

Why?

Consent to terms&conditions is not stored

This is a privacy tool - we only need to log consent to privacy

What is the use for the Privacy Extend Consent menu item?

Some countries are stating that you can only store the collected data for a period of time and after that period you need to get further consent

I would advocate for smaller but more PRs...

All development took place in a public repo where everyone was encouraged to test and of course in that repo everything was in small, single function pull requests.

Ok, correction, I did not test everything. I did not test setting the privacy policies and the terms and conditions to an article and I did not test updating an existing site to 3.9 with these changes.

Timestamp is always displayed as UTC. I would expect that timestamp to be in the users/sites timezone, maybe with a tooltip with the UTC time

Which one - user or site - they are not the same

As with all formatted times in Joomla, the users timezone overrides the sites timezone.

Times in this component are nicely formatted, but I'd say we need the exact timestamp at least as a tooltip.

Why?

Because when I'm being called by a user on the phone and they claim "hey, I never consented!", I would like to tell them "Yes you did. On july 4th, 19:34:55" and not "a day ago." You can look up the specific date in the database, but that requires quite some knowledge from the admin.

Consent to terms&conditions is not stored

This is a privacy tool - we only need to log consent to privacy

Then add this as a separate logging event into the actionslog. With this checkbox being a new feature and thus existing users being forced to consent to it now, the date of registration and consent could be different.

What is the use for the Privacy Extend Consent menu item?

Some countries are stating that you can only store the collected data for a period of time and after that period you need to get further consent

I still don't understand how this would be used. Is this for collecting consent from the user every year or is this for renewing the data export request or...?

I would advocate for smaller but more PRs...

All development took place in a public repo where everyone was encouraged to test and of course in that repo everything was in small, single function pull requests.

I understand. I already wrote @mbabker privately that I'm sorry that I'm criticising like this while joining this late in the game. This is a major feature and execution by those involved in development has been very good. All my remarks are minor issues, the overall picture given by this PR is of a very professional feature.

Consent to terms&conditions is not stored

This is a privacy tool - we only need to log consent to privacy

Then add this as a separate logging event into the actionslog. With this checkbox being a new feature and thus existing users being forced to consent to it now, the date of registration and consent could be different.

Not really a new feature. Just extracted the one from the user profile plugin so you can use just this one field without needing all the others. Unlike the privacy plugin which when applied forces all existing users to consent on login this tos plugin does not force anything on existing users.

What is the use for the Privacy Extend Consent menu item?

Some countries are stating that you can only store the collected data for a period of time and after that period you need to get further consent

I still don't understand how this would be used. Is this for collecting consent from the user every year or is this for renewing the data export request or...?

Its for "extending the consent"

IP address sanitization is not IPv6 compatible

$ip = JFactory::getApplication()->input->server->get('REMOTE_ADDR'); probably needs to use the string filter versus the default cmd filter.

Timestamp is always displayed as UTC. I would expect that timestamp to be in the users/sites timezone, maybe with a tooltip with the UTC time

UI needs to make use of JHtml date helpers as is normal elsewhere

Should anonymous actions be logged, too? Specifically sending a request via the com_contact form.

Right now this is purely intended to catch authenticated user actions

If you fail to assign a user when creating a request in the backend, you can not edit this afterwards. I understand that this most likely isn't possible for auditing reasons, but maybe we should add a prominent note?

I've been asking for UX feedback from day one. Yes, once created a request cannot be modified (unlike other parts of the system where you do have full edit capabilities). How that's communicated still needs some thinking but it's an issue I'm aware of.

Times in this component are nicely formatted, but I'd say we need the exact timestamp at least as a tooltip.

There are tooltips for the exact time, as well as the timestamp being available on the item view instead of using the relative date string

Stupid question, but: Don't we have to include the content of the specific user of the actionlog in the export, too? And if there is no data for a domain in the export (no user notes for example) shouldn't that whole domain be left out?

Don't we have to include the content of the specific user of the actionlog in the export, too?

Thinking back on it, we probably need to add plugins for:

• Action logs
• Contacts (including custom fields)
• Content (including custom fields)
• Messaging (this one gets kind of interesting because through the UI you can't read someone's messaging threads (in the database you can) but the export would expose those to a super user)

For categories and tags, I would suggest these are NOT the user's data for export as it relates to the site's content hierarchy (it would be kind of like including menu items simply because you were the one who created them if we tracked that data). That doesn't stop anyone from writing plugins to include it but from a core perspective I think we don't need to worry about it.

And if there is no data for a domain in the export (no user notes for example) shouldn't that whole domain be left out?

I think you can approach it either way. An empty domain explicitly says "we don't have any data of this type on you". Not including the domain doesn't really expose its presence (or the fact there's no data).

I have installed the suite full package from the given link to test but the component is not showing up in the admin menu. Com_Privacy show in the admin component file tree but on installation no menu item is created (checked on PHP7.1 and PHP 7.2/Mariadb/fastcgi)

Check Users menu, it should be there

Thanks Tuan, Did not realize to look for a component under "Users" I have updated the documentation page so users know where to find it.

I have created a menu link to the "Request Form Menu Item http://gwsdev2.site/index.php?option=com_privacy&view=confirm&Itemid=110&lang=en but the Status Check does not update to "published" I have also created a URL link in which I copied the "given link-id. Also that does not change the publish status. Is this a bug or do I miss something?

Did you publish a menu request too (ie not only a confirm menu item) ?

Nice catch @alikon that did the trick BUT we still have something not working properly.... As mentioned I created a menu type "URL" and entered the 'give' url i.e. "index.php?option=com_privacy&view=request&Itemid=101&lang=en" (See site http://gwsdev2.site/index.php?option=com_privacy&view=request&lang=en&Itemid=101) and menu type "URL" does not update the status check

@mbabker I'm trying myself on the actionlogs plugin for the privacy part. Question: Should you be able to delete actionlogs data? And what to do with entries that are not created by a user, but have the user as subject? For example an admin created a user. Should we have an optional magic variable in the message, for example userid or userID, on which we can react? We could do a SELECT * FROM #__action_logs WHERE message LIKE '%"userID":"ID"%'

Scenario
Super User logged from frontend, submit a deletion request using a different email address (not linked to the Super User account, but to another registered user), confirmed the request via email.
Request is confirmed, but in Privacy Dashboard it results linked to the admin account.

Expected result:
Request should be processed and not linked to the admin account.
Actual result:
You can't process the request because it's seen as deletion of Super User.
Inserted Email address is not checked against the user account data (while logged in).

At this point we should avoid giving the opportunity for a logged user to insert a different email address in the deletion/information request and pre-fill the field with user email address (non-editable).

While submitting a Deletion Request the email received by the user has the following subject:

For clarity it can be changed to "Information Deletion Request" in case of deletion, giving that the current subject is instead perfect for Information Requests.

Scenario

1. Submit a request of deletion (while logged in as registered user),
2. Confirm the deletion request via email
3. As admin in the backend, process the request and delete personal data.
4. User account is anonimized and data deleted as expected.
5. User account is blocked.

Expected result
Any active session of the user is purged and user can't login anymore.
Actual result
If the user has an active session, it will be anonymized: username changed to "ID XXX":

User is still logged in and can operate in the website, including visiting his profile:

After logout and trying to login again, user can't login (as expected).

Is it an intended behaviour to allow the admin to "process" several times a request?
Let me explain:

• a user submits a deletion request and confirms it.
• an admin processes the request and delete data.
• the admin forgets to click on "complete request", so the request is still pending.
• the admin goes back in the request and click again on "Delete Data" (but data has been already deleted previously).

So should we force to complete the request, once the data has been deleted? Maybe disabling the "Delete Data" button.
Also because in the audit log on the right you can see if you already clicked on the Delete Data button.

Following #20800 (comment)
it can lead to potential information disclosure because it sends via email to any email address data about the logged user account.
If the user fills out Information Request form using a different email address, he/she can confirm the request (from this third party email address) and once processed receive the XML with all user data.

If the user fills out Deletion Request form, in the same way, using a different email address from the one registered in the account, he/she can confirm the request and all data of the user can be deleted.

The risk is extremely low, because you need to be logged in as the user, to receive/act on such user data, but imho the request form should allow to use only the same email address specified in the account details for the current user.

The system is designed to support requests for users who do not have an account on the website (as an example, a site which has a commenting system installed in which you only provide a name and email address when commenting but do not register for an account). This is why the user field when creating a request from the backend is not a required field, and why the email field when creating a request on the frontend is not hardcoded to a single account.

As mentioned I created a menu type "URL" and entered the 'give' url i.e. "index.php?option=com_privacy&view=request&Itemid=101&lang=en" (See site http://gwsdev2.site/index.php?option=com_privacy&view=request&lang=en&Itemid=101) and menu type "URL" does not update the status check

Create the external menu item without the Itemid segment (the database lookup is basically for index.php?option=com_privacy&view=request, which is how the URL is created when using the "Privacy > Create Request" menu item type)

Should you be able to delete actionlogs data?

No, this is a site audit log and should not be removed until regular log rotation/purge happens.

And what to do with entries that are not created by a user, but have the user as subject? For example an admin created a user. Should we have an optional magic variable in the message, for example userid or userID, on which we can react? We could do a SELECT * FROM #__action_logs WHERE message LIKE '%"userID":"ID"%'

Honestly, not sure yet how to approach this one. @alikon or @joomdonation any thoughts?

Is it an intended behaviour to allow the admin to "process" several times a request?

Yes. We are not arbitrarily performing the "complete request" transition at any time. In the case of an export action, it is entirely feasible that an admin may run the export multiple times before completing it (downloading the XML for review before emailing). In the case of a deletion this shouldn't cause any harm other than generating a new random username as everything else is either changed to a semi-predictable value or deleted based on the user ID.

If the user has an active session, it will be anonymized: username changed to "ID XXX":

Fixed via joomla-projects/privacy-framework@50c526f

This is why the user field when creating a request from the backend is not a required field, and why the email field when creating a request on the frontend is not hardcoded to a single account.

Yes, but, actually you need to be logged in the frontend to submit a request and even if you enter another email address than the one in your account, the request is linked to the logged user.

Yes, but, actually you need to be logged in the frontend to submit a request

It's an artificial thing that could be removed at any time. The only concerns with doing so are:

• Spam protection
• Should an unauthenticated user be allowed to create a request for an email that has an account

I'd keep mandatory login to submit a request (even thinking the example you mentioned in the previous comment about blog+comments).
What i think it should be changed is the fact that you can insert a different email address instead of using the one linked in the profile.
So imho it should be:

• logged user -> request goes to the email address specified in the user profile.
  and if we allow guest requests:
• unauthenticated user -> request goes to the specified email if it's associated to an existing user profile (as it works now for the "Forgot Password").

Hi, I'm a new tester here. I found several problems in the new feature "Latest Actions"
When I create a menu item from the administration in the module "Latest Actions", will show the following:
User test trashed the menu item Create Request, Confirm Request or Extend Consent.
Clicking on the links: Create Request, Confirm Request or Extend Consent
I will get this error: Invalid controller: name='menu_item', format=''

I've lost track of the issues that came up here. Can we copy everything over as separate issues into https://github.com/joomla-projects/privacy-framework ?

Yes.

yes please new issues on privacy-framework

I'll see what I can do in about 2 hours.Am 06.07.2018 15:49 schrieb Nicola Galgano notifications@github.com:yes please new issues on privacy-framework

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

Just upgraded my dev system to it, first thing I would say is there is a reference at the bottom of the initial privacy form that appears when you confirm agreement to a privacy policy, but there is no policy (Yes I appreciate I will have to create one) or link to any policy. May I suggest that a "raw default policy" is included, that can be updated/edited by the admin, and is linked to prior to the user having to click the agreement policy button.

@b10tds You can set the right message in the "Privacy Consent System" plugin and link to that document. However I agree with you and will open another issue for that at the other tracker.

I went through this whole thread and hopefully opened an issue for each thing that was discussed here and is not yet resolved. I mentioned the original authors each time for notification purposes. Feel free to open another issue if you are missing something from you. @mbabker will probably be swearing like a sailor by now with all the notifications... ?

As we have a dedicated team of experts on this topic is it too much to ask for all of them to review this. https://volunteers.joomla.org/teams/compliance-team

Hey, guys. How can I help with testing the PTS? I installed it. What's next? Cheers!

Hey, guys. How can I help with testing the PTS? I installed it. What's next? Cheers!

@alexsmirnov73 you can install the 3.9 build downloaded from https://developer.joomla.org/privacy-pack/ install it and test it.
Extensive tests should be done in the Privacy component, the usage of Information Request / Deletion Request, Action Logs.
To effectively test the release and the features of 3.9, you should have the opportunity to send emails (that's how the Request part works), so i'd avoid using local installations.

Today I have finally gotten round to give this a check and my first observations are:

• So it tells me the Privacy Policy is not published but there is no information on how to publish it
• Same with the Request Form Menu Item Published

No clue what to do with these two. It would be good to have info on what I should do on how to resolve these issues.

In the user action logs a username is hyperlinked to the edit page of the user. What is the use of this?

The dropdown should be having a class of advancedSelect I think.

I received 2 emails regarding the System - Privacy Consent plugin:

User admin updated the plugin System - Privacy Consent | 2018-07-12 21:22:00 | Plugins | Super User
-- | -- | -- | --

User admin published the plugin plg_system_privacyconsent | 2018-07-12 21:22:03 | Plugins | Super User
-- | -- | -- | --

Notice that in the second email, the name of the plugin is not translated.

User user logged in to site | 2018-07-12 21:25:53 | Users | user
-- | -- | -- | --

Should this tell me which site the user logged into?

These are my initial findings.

There's no action text for high urgent request count either, just for reference.

So it tells me the Privacy Policy is not published but there is no information on how to publish it

This one's not easy to do because it is based on plugins giving a positive response (the policy isn't stored in the privacy component or known by it, you have to configure it in a plugin and based on your site's workflow you may end up with a custom plugin with a privacy policy created in another content component; it'd be weird to tell someone "Go to 'Content => Articles', create a new article, publish it, assign it as the privacy policy article in this plugin..." if they're using K2 for example).

Same with the Request Form Menu Item Published

I guess if we're going to add a help text on how to make the status green we could add a "Publish a 'Privacy => Create Request' Menu Item" note.

In the user action logs a username is hyperlinked to the edit page of the user. What is the use of this?

Truthfully, I don't know if we actually NEED to link every username reference. There's a part of me that suggests we can kill this link and leave the link to the item managed (user edited, request processed, article edited, etc.) in place.

The dropdown should be having a class of advancedSelect I think.

Added Chosen to the layout.

it'd be weird to tell someone "Go to 'Content => Articles', create a new article, publish it, assign it as the privacy policy article in this plugin..." if they're using K2 for example).

Understand but perhaps we can link to documentation at jdocs?

The docs would still assume the workflow of you are only using the core provided tools. The point here is that the check for having a privacy policy published is based on a plugin saying "yes, we do", and that plugin can use any source for its policy. So as soon as we put any kind of instruction about "to publish the privacy policy do this" and it doesn't apply because the user isn't using our core plugin or com_content to create the policy article then it's just as confusing (if not moreso) than not giving any kind of guidance. You would almost have to have the plugin provide the help text, but that too can get confusing if you manage to have multiple plugins installed and active responding to the event which asks if the policy is published.

@mbabker So we created such a flexible workflow it cannot be documented ?

When I publish/unpublish a plugin from the list view, the plugin name is not translated in the action log email. Editing and then Save & Close a plugin does have the name translated.

Should we have a filter for urgent requests?

On every action I do I get an email, I guess it would be nice to have the option to get an email over a set period of time.

,"logs_notification_option":1,"logs_notification_extensions":["com_banners","com_cache","com_categories","com_config","com_contact","com_content","com_installer","com_media","com_menus","com_messages","com_modules","com_newsfeeds","com_plugins","com_redirect","com_tags","com_templates","com_users"]}

I have a regular user that has these settings in the params field. Now I don't know how I managed that but I went to investigate.

It is possible when you create a new user that is not part of the Super User group to set the mail notification to Yes. Since this should be limited to Super Users, we should check on that when saving the user.

The events are also all selected by default while I think it is better to not have them selected at all, so users cannot get accidental emails about changes. Like in the modules we can have a toggle all/none button.

After I saved a regular user while I was on the User Action Log Options tab and then edit that user, no tab is active because that tab is no longer available. This is a minor thing I would say.

So we created such a flexible workflow it cannot be documented ?

It's not that it cannot be documented. It cannot be documented with a help pointer embedded into the code to be rendered in the UI. The docs wiki and third party tutorials can fully document the core workflow. We cannot put a pointer in the UI because of the flexibility unless we make a special content type in com_privacy and duplicate the relevant parts of com_content (both the site and admin application capabilities) so that there is only one way to publish a policy that fits the component workflow.

Should we have a filter for urgent requests?

There is but isn't. Essentially it's all confirmed requests sorted by age, oldest first. Urgent is only urgent as it relates to saying "these are potentially overdue", it's not a status, and it's a configurable value. I'm not even sure you could write such a filter for the search tools integration in the core models.

On every action I do I get an email, I guess it would be nice to have the option to get an email over a set period of time.

Would be nice but the complexity on that would be pretty high (as then you'd have to have tracking on each log item that was emailed to each user so the system has a way of saying "send all actions after X"). If someone wants to work on it then please do but personally I don't consider that feature a release blocker.

It is possible when you create a new user that is not part of the Super User group to set the mail notification to Yes. Since this should be limited to Super Users, we should check on that when saving the user.

It doesn't matter if the params are saved to the user record or not, as long as everything else is correctly filtering user accounts when things are processed.

It doesn't matter if the params are saved to the user record or not, as long as everything else is correctly filtering user accounts when things are processed.

That is not the case. The Registered user I created is receiving Action log emails. There is no way for me to turn it off for this user without promoting the user to Super User first.

It's not that the parameters are saved to an account that's not a Super User. It's that the process that's deciding who to notify isn't also validating the account is a super user and is making assumptions. We should not be adding or removing parameters to a user account based on their group assignments being changed.

Fine.

@mbabker Dang that was quick. Nicely done mate :)
LC6 from set language now used in CSV

Regarding the privacy policy and different content components: I'm looking at the plugin and really wondering why we are selecting an article and not simply a menu item... I think requiring a menu item for the privacy policy is okay.

@roland-d You've brought up quite a lot of good points and it would be a pity if they would get lost. Can you add issues for all of this here? https://github.com/joomla-projects/privacy-framework/issues

basically it is the exact same code/principles as the current tos field in the user profile plugin - which has been present since 2.5 iirc or maybe even earlier - and why require a menu item if you dont need one?

Because it allows us to tell people "hey, you haven't got a privacy policy setup. Make sure that you have something set in the privacy plugin" and not at the same time lock them into com_content.Am 14.07.2018 23:37 schrieb Brian Teeman notifications@github.com:basically it is the exact same code/principles as the current tos field in the user profile plugin - which has been present since 2.5 iirc or maybe even earlier - and why require a menu item if you dont need one?

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

Personally I am not in favour of the warning in the first place. It could be that the site owner chose to only display a short notice within the plugin and not link to an article at all.

And insisting on a menu item for the policy is not necessarily something that a site owner wants to have

But rather limiting to a menu item, than limiting to just an article.

It's only limited to a com_content article if you use the core provided tools. It is not a hardcoded dependency as pointed out, one can swap to use another plugin that supports their preferred content component. Setting a menu item in the plugin just changes the plugin's dependency. IMO there is nothing gained by requiring a menu item over an article.

@roland-d can you please create issues in the tracker of the https://github.com/joomla-projects/privacy-framework/issues repo for your findings?

I thought my points are moot.

You brought up several issues and I think that most of them are valid and should be discussed properly and not as 2 lines in a 30 line comment between 60 other comments.

I have tested this item ✅ successfully on 2191036

I have tested this item ✅ successfully on 2191036

Thank you @mbabker for this great implementation

Our JUG tested the privacy tools suite at our PB&F today. Six of us all installed (both on existing sites we upgraded and new fresh builds). We added privacy policy articles and menu items for all the new privacy menu item types. All of them worked fine.

We created new contacts and new contact forms and thanks to Michael added the privacy policy checkbox to it and enabled that consent plugin. We added both privacy policy and t&c articles/checkboxes for new user registration.

We tested the Create Request menu item with both export and remove, worked just fine.

Tested Extend Request menu item and that worked fine too.

We tested the snot out of everything we could think of with the privacy tools suite and all worked fine.

It was a little confusing to figure out what to do so another thanks to Michael who helped us know how to find stuff.

Also, we did this testing on localhost and SiteGround and Rochen.

Is there somewhere a documentation how to set up and use the Privacy Tool Suite?

@TobsBobs we used this info:

https://developer.joomla.org/privacy-pack/

https://community.joomla.org/blogs/community/joomla-needs-your-help.html

https://docs.joomla.org/J3.x:Privacy is where it's going in the docs wiki but there is still a LOT of documentation to be written here.

Seriously? There were loads of people that said they wanted this feature and stood up to be testers and yet hardly any of them have bothered. Maybe we should just drop this. It's a major new feature and if its not widely tested then I would be very reluctant to add it.

what's the problem ?
< sarcasm > just merge it like some 4.0 pr's </ sarcasm >

I have tested this item ✅ successfully on e1f599a

I've installed it a lot of times since the beginning. I did fresh installs, updated several existing sites, tested all features of the privacy and actions log components, as well as ToS.
All work as expected.

I have tested this item ✅ successfully on e1f599a

I have installed and tested the Privacy Tool Suite.

Tests:

• privacy dashboard
• publish a privacy policy
• menu item created
• privacy Consent
• export
• and played with some users.

I have to say it works very well.
Thank you guys. This is a really good job you have done here.

I have tested this item ✅ successfully on e1f599a

Works perfectly.
Thanks for the huge effort spent on that!

Tested privacy suit e1f599a functions seem to work fine. Currently on holiday but available for testing after 15 aug...

It's a major new feature and if its not widely tested then I would be very reluctant to add it.

@brianteeman I've tested some parts, but not all (i was on Vacation when this PR was created). ;-)

First, good work has been done since my last view in the repository.
I can't mark yet my test as i didn't have tested all, but looking at other testers success, seems ok with core integration.

About 3rd party integration, i didn't have yet the time to test all.
Does any 3rd party extension developer has tested integration with Privacy Tools ?

@mbabker can we merge it please? :)

We are not done with the development yet. There are currently still 9 open issues on the privacy issue tracker and a few of those are critical.

glad to hear that you're working on that @Hackwar
i just wanted to be sure that this was not on-hold

@Hackwar can you mark/recap on https://github.com/joomla-projects/privacy-framework/issues wich are the most critical in your opinion....

We need to work on all ids with a number >100. But the most important are joomla-projects/privacy-framework#158, joomla-projects/privacy-framework#188, joomla-projects/privacy-framework#206 and joomla-projects/privacy-framework#210

• joomla-projects/privacy-framework#210

is not something that we can consider "critical" is much more about personal feeling

• joomla-projects/privacy-framework#158

maybe yes looking forward for your pr

• joomla-projects/privacy-framework#188

Core is only supporting logging of privacy policy consents, so not so critical for me, again personal feeling

• joomla-projects/privacy-framework#206

maybe yes looking forward for your pr

I've provided PRs for 158, 188 and 206: joomla-projects/privacy-framework#224 and joomla-projects/privacy-framework#225 Please help and test these. I think we should still tackle 210 to make this consistent (as in using singular everywhere) but I don't know when I will be able to work on that. So if someone wants to help out here, that would be very helpfull.

There are 4 open PRs and joomla-projects/privacy-framework#210 which should be handled before we merge this into 3.9-dev. The other open issues are rather minor and could be dropped, if we decide so. So the moment we have those 4 PRs and 210 solved, we could push a 3.9 beta from my POV. (Feel free to correct me here, @mbabker ?)

The cron stuff, while a nice to have, isn't a blocker to getting this merged (though I'd definitely like to see it merge sooner than later). TBH I haven't given it proper attention yet, just been busy.

Just setting an expectation on this one. We definitely should push to get it finished and included, but if we can't, there are still viable alternatives to working without it.

Confirm Consent Plugin
For our email related forms (contact, email to a friend, and the privacy policy form), this plugin adds a consent checkbox....

I have tested (offline) the 'contact' and 'the email to a friend' capabilities.
The last one let see an error. So it is not possible to send an email to your friends.

Note: I do not know if this is the place to report this issue.

I see only two types of request, remove and export. I'm missing the information request.

at the moment there are remove&export request,
what should be the "information request" ?
can you elaborate a bit more

@rachelwalraven The export request is the information request. By creating an export request, you will get an export of all the data, that the website has about you.

This PR is sitting here since more than 2 months. It has been tested by many users, no major issues or release blockers has been reported AFAIK.
Is there any VALID reason why this PR has not been reviewed/merged or anything by CMS maintainers?
The community is waiting for these features. Are we going to let this PR die, and put to the trash the great work of a small bunch of volunteers???

Or even an invalid reason so we know what to address

All maintainers have tested this PR so can't merge it ?

Didmt expect an invalid (and untrue) reason so quickly;)

This is a PR that has a sub-project with its own issue tracker and in the 2 months a lot of issues have come up and have been fixed: https://github.com/joomla-projects/privacy-framework/issues

Rest assured that Michael would not delay the release of 3.9 if not necessary.

I’m not delaying anything, but I’m not going to personally merge a PR that
I oversaw a lot of the project effort on without adequate testing and
feedback. And for a while, that bit has been missing.

For me merging this triggers the release cycle. Unlike fields or routing or
4.0 features which got time to mature in a dev branch, this is basically
merge it and beta starts.

For me, it’s stable enough to do that. Others may have different
opinions. I don’t want to shove my opinion down the throat of others. And
I don’t want to ship something that has only been reviewed by those who
built it (with a few notable exceptions beyond that).

I’m one of a handful with merge rights. And not one who is technically a
leader within production right now. There are plenty of others IMO who
could/should provide feedback or make an informed decision.

On Sat, Aug 25, 2018 at 2:30 PM Hannes Papenberg notifications@github.com
wrote:

This is a PR that has a sub-project with its own issue tracker and in the
2 months a lot of issues have come up and have been fixed:
https://github.com/joomla-projects/privacy-framework/issues

Rest assured that Michael would not delay the release of 3.9 if not
necessary.

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

--

• Michael Please pardon any errors, this message was sent from my iPhone.

By curiosity, I did a grep for new file mode on this .diff
This PR adds 188 files to Joomla.
Quite a bunch of them are updates sql , postgres and sqlazure (14 each if I do not mistake)
Can't these be reduced?

Talk about trying to find a stupid reason not to merge this

"love is in the air"

I use this

Fully built "release" packages are available from https://developer.joomla.org/privacy-pack/

for test.

Some findings

COM_ACTIONLOGS_FILTER_SEARCH_DESC missing string.
If no actions logs to export, when clicking on Export All as CSV, we get

[27-Aug-2018 10:50:18 Europe/Berlin] PHP Notice:  Undefined variable: extensions in /Applications/MAMP/htdocs/joomla39/administrator/components/com_actionlogs/models/fields/extension.php on line 55
[27-Aug-2018 10:50:18 Europe/Berlin] PHP Warning:  array_unique() expects parameter 1 to be array, null given in /Applications/MAMP/htdocs/joomla39/administrator/components/com_actionlogs/models/fields/extension.php on line 55
[27-Aug-2018 10:50:18 Europe/Berlin] PHP Warning:  Invalid argument supplied for foreach() in /Applications/MAMP/htdocs/joomla39/administrator/components/com_actionlogs/models/fields/extension.php on line 57

@infograf768 can you open a new issue on https://github.com/joomla-projects/privacy-framework
please

Thanks to all the involved people here, great job!!

@mbabker would you like to tackle the open issues here or keep working in the privacy repo?

@infograf768 your report #20800 (comment) should be fixed here joomla-projects/privacy-framework#240

@laoneo , @mbabker
imo should be more manageable keep working in the privacy repo (where we have already open issues & pr's)
but there will be no issue if you decide is better to work on the 3.9 main repo ?