General developer forum

GDPR and Privacy - What it means to be plugin developers. Urgent request for comments

 
Picture of Andrew Nicols
GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi all,

For the past few months we have been focusing our development efforts at Moodle HQ on a major project to allow compliance of the incoming European General Data Protection Regulation (GDPR). This EU directive is due to come into place on the 25th May 2018.

Why should I care? - I'm not in the EU

Although this is an EU directive, it does affect everyone. If you have any users who are EU citizens then they have a right to invoke this law, and many non-EU countries around the world have arrangements in place which mean that organisations within those locations must also comply.

Why are you telling me all of this?

Well, under the law, users have a whole set of new rights, and these rights will affect all Moodle plugins. Amongst other things these rights include:

  • the right to request information on what types of personal data you hold, along with how each instance of that data is used, and how long you intend to keep it for;
  • the right to request a copy of all personal data that you hold; and
  • the right to request deletion of all personal data that you hold.

In short, we're telling you because you will need to take action to ensure that your plugin can comply with the EU legislation.

This document only describes the part of the ongoing work which plugin developers need to be aware of.

What if I don't update my plugin to comply?

If you do not update your plugin, then any site which intends to use your plugin will not be able to fully comply with the requirements of GDPR, and they may be required to uninstall your plugin as a result.

Whether your plugin implements the privacy API may also be indicated within the Moodle Plugins database.

What does this mean for me as a plugin developer?

In short it means that you need to provide a way for that data to be described, exported, and deleted.

That sounds intense. Can't Moodle do that for me?

Moodle would love to do all of that for you, but unfortunately the core codebase does not know what your plugin does, what information it stores, how it stores it, what format it is stored in, and what that data really means.

However we are working on a new Privacy API which will make this much easier for you. It's that API that I'm posting about now as we have been considering how best to allow you to fulfill all of the requirements of the new legislation, whilst keeping things simple, efficient, performant, and keeping both plugin developers and the requirements of the legislation in mind.

We'd love some feedback on what we have so far. We have limited time available to get this functionality complete, so we don't have much time to get feedback.

The proposal

We intend to create a new Privacy Subsystem. This contains a number of PHP Interfaces which we encourage you to implement.

We have tried to keep these Interfaces clear and concise with minimal coding required for developers.

We have written some documentation which gives hints on how the API is structured and answers a number of Frequently Asked Questions.

We have also pushed a working prototype of this code to https://git.in.moodle.com/gdpr/sar/tree/MDL-61306-master. Please note that this branch is a work in progress and is subject to change.

We have a working prototype of the GDPR Subject Access Request Tool at https://git.in.moodle.com/gdpr/sar/tree/MDL-59718-master. Please note that this branch is a work in progress and is subject to change.

Finally

We would love to have some feedback on this plugin. We do realise that it is a complex API, but we have tried to ensure that it is not overly complex for plugin developers whilst fully implementing the spirit of the new regulations, as well as any similar regulations and laws which may be implemented in other countries too.

Thanks,

Andrew, Adrian, Al, Barbara, David, Jake, Jun, Zig, and all others involved in the team.

 
Average of ratings: Useful (21)
Picture of Valery Fremaux
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Thanks a lot for your efforts providing a clean and ready to use API for GDPR compliance. We do have a ton of questions of our administrators about when we, independant developpers, moodle partners or other cases will be ready to ensure the compatibility.

We will read quickly and carefully the provided documentation, and would like to know the hypothetic forecasted stability (sufficiant stability) calendar of the proposals to start our upgrading process on key plugins.  If this leads to significant efforts at developer side. i guess many developers will not like to start implementing in a moving swamp wink.

So do you think real anticipation coding work can be done yet, or should we wait for some "release candidate" advice ?

I will be happy to be one of the early tester/implementer in the plugin side...

Sincerely

Valery / 160 plugins to upgrade wink

 
Average of ratings: Useful (2)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Valery,

Thanks for the reply and thank you for taking the time to read through the API. I look forward to any specific comments or queries that you may have.

We are hoping to finalise the calendar on this shortly, but we plan to release the complete API (that is the core implementation, and most of the relevant subsystems) for the next Moodle point release.

Our intention is to include these changes in Moodle 3.3 and Moodle 3.4 as soon as possible. In order to do so we are working as quickly and thoroughly as possible to find any unexpected issues, edge cases, missed functionality, etc.

Right now you should wait for the point release as the APIs are currently slightly unstable. Mostly we are just making minor changes to them - a few class renames and namespace changes, but nothing too major now.

If you'd like to have a go at implementing in one of your plugins then that would be great (for us) and would give us some real feedback on potential issues, but please be aware that there are still some small changes to be made. If doing so I'd recommend you base your work on MDL-61307 (that what we're doing) and take a look at MDL-61309 where I've done that for forum.

I will push my current testing script to MDL-61309 too.

Andrew

 
Average of ratings: -
Picture of Valery Fremaux
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Thanks Andrew for your complete answer.

Receiving also the Moodle Partner tracks about GPDR, i can have now a better global picture of the implementation progress.

We will wait all the bricks assembling together of course, and give you followup of what we can test.

I have one pending questionnning about some plugin structures :

As far as a plugin that simply holds data for each user in a separate way looks clear to me, I'm wondering how should we consider and process cases where the plugin holds a real collaborative multi-user collaboration. Specially for deletion (data catalog may not be concerned as long as it just describes data assets that really belongs to user, although...)

One concrete case :

Tracker plugin (mod_tracker)

Holds issues belonging to a submitter (clear ownership), commented by other members (clear ownership on comment), assigned to other users (so they can add some data in it - starts being tricky), has an event track (some events where registered on behalf of one of the operators)...

Is there a general guideline to weight and decide about the GDPR application on multiple users shared information ? 

Cheers

 
Average of ratings: -
Picture of Michael Hughes
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersPlugin developers

I'm not sure that there is *general* guidance on this, you can only work with specific guidance for the case in question.

We had a similar concern with one of our internal plugins where user's are asked to rate other members of their group and provide a comment. The task can be configured by the teacher so the subject and conditions the student is making a judgement on can't be known by the plugin.

The guidance we've had is that:

  1. The rating *of* a student is personal data of the student *being* rated because it is applying a judgement to them which they may ask to be aware of.
  2. The comment made is personal data of the student *doing* the rating. However if the comment contains something *about* another student then it would *also* be the personal data of the other student. 

So as a plugin developer we need to have made this consideration for the specifics of our plugin. 

This is a big problem with everything that may be considered user-generated content, the author is probably easily tracked, but the subject of the content may not be. So it's problematic to include comments held in this tool as part of an SAR, where the Access Request is *not* the rating student.

The decision we're pondering, under the right to be deleted conditions, is whether or not to apply something like Moodle's forum rules and blank the comment if the rating student makes a deletion request (subject the the category & purpose applied to the context).

There is also no tool in Moodle that would allow user-generated content to be attached (manually) to a context (e.g. attach a comment about a user to the target user's user context).

Hope this helps (or at least shares some pain!)


M

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersParticularly helpful MoodlersPlugin developers

How far have you got thinking about how the privacy API will work with question types?

I am thinking that the questions a person created are probably not personal data (except, what about mod_qcreate? Hmm). Quiz attempt data is, but that is all stored in quiz tables. There is little that is qtype-specific. It may be the case that qtypes don't need to implement the API, just quiz and similar modules.

Anyway, am happy to discuss it with you further if that would help.

 
Average of ratings: Useful (2)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters
Hi Tim,

Thanks for the fast reply.

I’ve begun to look at quiz and how it relates to the question engine and qtype plugins and have a (very bad) implementation which gets the basic question attempts but it isn’t using the APIs properly yet.

I’m hoping we don’t need to pull from the question subsystem to the qtype plugin type. Looking at that side of things is my next big ticket item.

If you have any thoughts on the best way of handling it they’d be appreciated.

My thought was that we would ask the question api to store question attempts based on each quiz attempt - a little like I’m doing in the rating API.

I’ll try and spend some time on it early next week.

Andrew
 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersParticularly helpful MoodlersPlugin developers

Some thoughts. Yes, the rating and comment APIs are likely to be good parallels.

The abstraction in the question system that corresponds to a quiz attempt is a 'question_usage'. A question_usage is a list of question_attempts (one for each question in the quiz). So, that natural API is for the quiz to be able to say "extract the data for this list of usages" (becuase they belong to this user). Might also be useful to have a more fine-grined API to just extract the data about one question_attempt, in case any activity needs it.

It may not be necessary for qtypes to implement anything, because they already implement a 'summarise_response' function. Basically, if you look at the output the core_question_renderer::response_history, then that is basically the full information about one student's interaction with the question (including things like teacher manual comment and grade). So, returning that same information, but in the data format the API expects is probably what the extract_question_attempt function needs to do.

If that is true, then there is no work for question-type plugins, which woudl be good.

As I say, if you can get online at a time when I am online, then I am happy to have a synchronous discussion with you.

 
Average of ratings: Useful (2)
Picture of Mike Churchward
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developersPlugins guardiansTesters

Something else to think about (unless you already have) is how plugins will be validated to have met the privacy system requirements. For example, it looks like it would be pretty easy to release a plugin with the \core_privacy\metadata\null_provider implemented, indicating that it does not store any personal data. How will we verify that this is in fact correct?

mike

 
Average of ratings: Useful (2)
Picture of Matteo Scaramuccia
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Hi Mike,
good question: guessing that the new validation check will report that the plug-in is using the Privacy API but somewhere there will be a disclaimer that using it is a necessary condition not a sufficient one since the proper using will be documented and "certified" by the Maintainer under her/his responsibility.

HTH,
Matteo

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Mike,

Thank you for the question.

Ultimately we currently have no way to enforce this though there are certain situations which we can probably detect and warn about though.

I suspect that we will add this to the manual review stage for new plugins being added to the Moodle Plugins database.

We should also be able to detect whether certain subsystems are in use, and we may be able to inspect the install.xml to see if there are any links to the user table. The mere presence of a database table does not necessarily imply user data, but the presence of a user data field does.

Ultimately there is some degree of trust, and I suspect that people will raise issues against those plugins which do not implement the API. I do hope that plugin developers will not outright lie.

Much of this detail is yet to be decided, but hopefully this answers some of your queries,

Andrew

 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

RE: "Ultimately there is some degree of trust, and I suspect that people will raise issues against those plugins which do not implement the API. I do hope that plugin developers will not outright lie."

My understanding after reading documentation about GDPR that ultimately it is the responsibility of the hosting / operating party and not the developer to comply with GDPR and therefore they must check the validity of the code for compliance.  Ok the developer can help, but if they don't tell the truth and you take their word for it then you're at fault and not them.

 
Average of ratings: Useful (1)
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Also... are theme setting values chosen by the Administrator considered 'personal data' as the represent the choice of an individual?  I'm not being funny here but a serious question.  The more I read up on GDPR the more confused and bogged down I get in the eurocratic legal babble.

 
Average of ratings: -
Picture of Michael Hughes
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersPlugin developers

As far as I understand it, the setting, whilst set by an admin, doesn't identify the admin.

So the value of *setting* isn't personal data, however the logs relating to the user setting said value could be.

 
Average of ratings: -
Picture of Mike Churchward
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developersPlugins guardiansTesters

Hi Andrew -

I doubt anyone would "outright lie", but there could definitely be a misunderstanding.

Is there a test that Moodle will need to run to "certify" core? If so, I wonder if that could be applied to plugins as well?

mike

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Mike,

Unfortunately there is no test that we can run to certify core. GDPR does not have a badge of compliance at all. Software is not 'compliant' with the GDPR, but the implementation of it can be (or can be audited and found to not be in breach of it).

Andrew

 
Average of ratings: Useful (1)
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Thanks Andrew,

In addition to my post on eLearningWorld -> https://www.elearningworld.org/collapsed-topics-eu-general-data-protection-regulation/ - for me what matters from a plugin developer's perspective is two fold:

1. Knowing what data constitutes 'personal data' under GDPR and thus then knowing that something needs to be done or not.

2. Plugin being called to respond (like an event) to the three rights:

  • the right to request information on what types of personal data you hold, along with how each instance of that data is used, and how long you intend to keep it for;
  • the right to request a copy of all personal data that you hold; and
  • the right to request deletion of all personal data that you hold.

So respectively:

  • Returning a description (in English, what about other langs).
  • Returning the data for a given user id.
  • Deleting the data for a given user id.

Thus for Collapsed Topics this would be:

  • "The state of the toggles in each course you have accessed that is in the Collapsed Topics format.  Kept as long as the user exists or a given course accessed by the user is in the CT course format".
  • You are using CT on the following courses (id - sectionno:open / closed): 34 - 1:open 2:closed 3:open, 48 - 1:open 2:open).
  • Toggle state deleted for user id 45.

Clearly the state of the toggles may not really be 'personal data' under the GDPR which is why the 'knowing' is so critical and I'm not in a position to hire a lawyer to find out.  If I had to then I'd just remove the persistence element of it.

Therefore what would really help is a clear definition of 'personal data' that developers can understand.  And therefore a simple core system that works like an event / remote method invocation / polymorphed method solution that asks the plugin to return the result of a given request.

Please note, I still need to read fully what MHQ has written.

And.... will Moodle HQ provide a lawyer support line who legally understands GDPR to say what does and what does not constitute 'personal data' to be made available to anyone who has a contributed plugin on Moodle.org please?

G

 
Average of ratings: Useful (1)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Gareth,

I'm sorry, but I'm not entirely sure what you're trying to say. Perhaps you can rephrase?

This discussion is specific to the API and trying to get appropriate feedback on it rather than a general discussion on GDPR.

As I mentioned in my original post, the API we have developed so far helps to cover:

1) the right to request information on what types of personal data you hold, along with how each instance of that data is used, and how long you intend to keep it for; and
2) the right to request a copy of all personal data that you hold.

We are currently working on the third item regarding deletion.

The API we have developed asks you to:

1) define which fields your plugin stores, alongside a description of each field.
These descriptions use Moodle language strings (as per the examples in the documentation we have written).
We will additionally provide an admin tool to allow administrators to specify a purpose and intended retention period for each instance Moodle context.
We feel that this combination of data being described, and admins defining a per-instance retention policy and usage information satisfies point 1.
2) Return all locations (Moodle contexts) in which your plugin stores data for a specific user.  In the example you give of a course format, the context would of course be the course to which a format is attached.
3) Store all personal data within each of those contexts.
We provide an API to allow you to store data (objects), related data (objects), Moodle files, custom file exports (e.g. iCal), and metadata.
It is not the duty of the API to tell you what personal data is and that is not really relevant to this discussion - that's really more a general GDPR thing and outside the scope of this API.

Personally I would say that the toggles should be considered to be personal data.

As we understand it, anything that can be used to profile a user must be considered to be personal data about that user. That includes IP addresses, text that the user has entered, preferences, times, dates, forum subscriptions, etc..

It's clear that you haven't looked at the API yet as we have provided basically what you've suggested.
We have done so via a series of PHP Interfaces which every plugin developer must implement as appropriate. This is not a suitable use of the Events system (I'm not really sure how you this relates), and I don't really know what you mean by a "polymorphed method solution".
PHP interfaces allow us to form a string contract with plugin developers so that we can ensure the data is retrieved in a sensible and convenient fashion for all developers.

I strongly doubt that Moodle HQ will be providing laywers for everyone to ask their questions. In most cases it's fairly clear which fields are user data.
I will ask the question and get an official response but I wouldn't get your hopes up. As a plugin developer myself I would not expect this and had not considered it.

Andrew

 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Hi Andrew,

Thank you for your reply.  Regarding "It's clear that you haven't looked at the API yet", no need to get nasty about this, please see: https://docs.moodle.org/dev/Moderator_guidelines#Flaming_.2F_personal_attacks.  GDPR can cause panic.

Ok, I'm asking from a developers perspective: Do I as a developer need to implement this?  Therefore specifically the key information pertaining to any API is the knowledge of knowing that you need to do something about it.  Therefore it's fine to describe an API but the key instructional introductory documentation would need to state along the lines of 'Use this API if....'.

As for feedback on the API, if another developer independently comes up with a design for a solution that matches what you have implemented then surely this is good feedback for the API that it confirms it's been implemented as needed.  A good thing!

By "polymorphed method solution" I mean 'Polymorphism' in OO - https://en.wikipedia.org/wiki/Polymorphism_(computer_science) - whereby the parent class has a method that is abstract and then the child classes implement their own implementation of such.

With "This is not a suitable use of the Events system (I'm not really sure how you this relates)" - I considered that the user requests for information and data are 'events' and therefore a possible solution to the problem could be 'event - reply'.  Thus plugins listening for a 'user requests deletion of personal data event' would process that event, perform an action and then 'log' / 'trigger a reply event' to confirm that they have done this.  Just an alternative way of looking at things.

I have no desire to start a bun fight, but am just asking questions.

Kind regards,

Gareth

 
Average of ratings: Useful (1)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Gareth,

I apologise - my previous comment was not meant to offend and I was not trying to be nasty. I'm sorry that my comment was misconstrued.

As I mentioned in my original post, this will affect all developers. You will need to implement this. Every developer will need to implement the new privacy API in some fashion if they want the sites that use their plugins to be GDPR compliant. If you do not implement this API, this will likely be displayed within the plugins Database, and sites which require GDPR compliance may be forced to uninstall your plugin (note: disabling is insufficient as existing content may contain user data).

With regards your comments on the "Events system", I'm sorry but I took this to mean the Moodle events subsystem, which incorporates a event + observer pattern. The Moodle events system is inappropriate for this body of work.

I am not looking to start a bun fight either, and I'm sorry that my comments were misconstrued.

Andrew

 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Thank you for your reply Andrew.

Looking at the documentation: https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit# - a few things come to mind:
  • With "Additionally, any free text field which allows the user to enter information must also be considered to be the personal data of that user." clearly this could mean for themes that have an unvalidated CSS checking Custom CSS box that the user could unwittingly enter personal data?  If so then themes will need to comply.
  • Clearly with my Collapsed Topics as I'm storing the user id, then I'll need to comply in terms of fully implementing the API.
  • With Mike's comment on "\core_privacy\metadata\null_provider" then is this enough?  Should there be an implementing function that returns in detail the developers explanation of the data the plugin stores (if any) that states that it is their belief that there is 'no personal' data.  But as developers are not lawyers then they could be wrong, therefore to have just 'null' is not a good thing.  Better for all plugins to explain what data they store and why fully, then be judged by peers / lawyers of using implementations that it is actually GDPR complaint.  Just like I explained in: https://www.elearningworld.org/collapsed-topics-eu-general-data-protection-regulation/.  Therefore 'null_provider' needs an method to 'explain why the plugin does not store data / or if it does why it is not personal' thereby demonstrating that the developer has 'really thought about it, rather than copy / paste, make a cuppa'.
  • As the document https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit#heading=h.qjyl7hmtrghj is under review, please could you add page / section numbers so that specific elements can be referenced here.  For example I want to comment on 'Describing the type of data you store' but think it's on page 14 etc.
  • With "Describing the type of data you store" with 'link_subsystem' does this mean settings in themes (the settings added to $ADMIN) and course format settings (as in their lib.php being the 'course_format_options' and 'section_format_options' methods)? and if so what would it be? So ‘core_files’?  If not then there would need to be other sorts of collection types.
  • Please could you expand on 'store_user_data' and 'store_user_preferences' as asking the plugin to store data it already stores?  I thought this would be a 'get request'.
  • 'get_contexts_for_userid' seems to me to be a part of describing the data and not exporting it so should really be in 'Describing the type of data you store' and not 'Providing a way to export user data'.
  • Generally the API seems to use 'store' and 'writer' verbs which seems counter to the purpose of 'getting and deleting' the data.  GDPR seems to me as to request information about what is being stored and to delete it if needed.  The plugin already 'stores' the data so using 'store' and 'writer' verbs indicates that the privacy API will duplicate the data.

Also:

  • How far back will the API be ported?  M3.3?
  • If backport, then will there be any differences between the Moodle versions?
  • Will the API be completed by the 25th March 2018 to give plugin developers time to implement it?

Kind regards,

Gareth

 
Average of ratings: Useful (1)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Gareth,

Thank you for raising these questions. I'll try to reply to each.

With "Additionally, any free text field which allows the user to enter information must also be considered to be the personal data of that user." clearly this could mean for themes that have an unvalidated CSS checking Custom CSS box that the user could unwittingly enter personal data? If so then themes will need to comply.

Personally I would say that system settings such as this where we anticipate code to be entered are a bit of a grey area. Additionally we don't really store the details of which users entered this content.

Clearly with my Collapsed Topics as I'm storing the user id, then I'll need to comply in terms of fully implementing the API.

Yes - this is a fairly clear-cut case of being user data.

With Mike's comment on "\core_privacy\metadata\null_provider" then is this enough? Should there be an implementing function that returns in detail the developers explanation of the data the plugin stores (if any) that states that it is their belief that there is 'no personal' data. But as developers are not lawyers then they could be wrong, therefore to have just 'null' is not a good thing. Better for all plugins to explain what data they store and why fully, then be judged by peers / lawyers of using implementations that it is actually GDPR complaint. Just like I explained in: https://www.elearningworld.org/collapsed-topics-eu-general-data-protection-regulation/. Therefore 'null_provider' needs an method to 'explain why the plugin does not store data / or if it does why it is not personal' thereby demonstrating that the developer has 'really thought about it, rather than copy / paste, make a cuppa'.

To be honest this isn't something that we had considered doing. We are going to look at adding a function (get_null_reason) which returns a langstring identifier within the component.

As the document https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit#heading=h.qjyl7hmtrghj is under review, please could you add page / section numbers so that specific elements can be referenced here. For example I want to comment on 'Describing the type of data you store' but think it's on page 14 etc.

I have added page numbers, but the document is also open to comments and suggestions. Google Docs doesn't make adding section numbers particularly easy.

With "Describing the type of data you store" with 'link_subsystem' does this mean settings in themes (the settings added to $ADMIN) and course format settings (as in their lib.php being the 'course_format_options' and 'section_format_options' methods)? and if so what would it be? So ‘core_files’? If not then there would need to be other sorts of collection types.

We don't believe that this means things like theme settings. Our primary focus is on the user belonging to actual users rather than administrators.

These settings are not preferences but site configuration - they do not allow you to profile a specific user -- maybe to profile how the site wishes things to work, but not a specific user.

Please could you expand on 'store_user_data' and 'store_user_preferences' as asking the plugin to store data it already stores? I thought this would be a 'get request'.

Perhaps we need to rename these, but I object to 'get' as this suggests that the functions will return the data, when they are actually storing the data in an export.

These are part of the request API which responds to users requests for their data.

Personally I feel that the naming is probably appropriate -- we are just thinking of it in different ways.

A user makes a reqeust for their data. The GDPR admin tool then gets the list of contexts, and finally asks the individual plugins to store all of the data in those contexts in an archiver, which we the serve to the user.

These are not getters.

'get_contexts_for_userid' seems to me to be a part of describing the data and not exporting it so should really be in 'Describing the type of data you store' and not 'Providing a way to export user data'.

Nope - this is definitely not a description of the types of data. The metadata part of the API is entirely dedicated to describing data in an abstract way not specific to instances of that data.

We only perform a get_contexts_for_userid in response to a user for their data.

Generally the API seems to use 'store' and 'writer' verbs which seems counter to the purpose of 'getting and deleting' the data. GDPR seems to me as to request information about what is being stored and to delete it if needed. The plugin already 'stores' the data so using 'store' and 'writer' verbs indicates that the privacy API will duplicate the data.

We have not yet completed the work on deleting data.

These APIs are currently focused on determining where the user has data within Moodle, and then fulfilling their request to obtain a copy of that data. It does so by storing that data in an export. Each plugin must write specific pieces of data to that export.

How far back will the API be ported? M3.3?

The intention is to backport this to Moodle 3.3, and Moodle 3.4.

If backport, then will there be any differences between the Moodle versions?

There should be no major differences between the versions but some versions may have different Moodle functionality to work with.

We had hoped to enforce return types within the API, but these are only available from PHP7.0 onwards, and Moodle 3.3 supports PHP 5.6 which means that we are unable to use them.

We have not yet determined whether we strip them all out in all versions, or just in the Moodle 3.3 version. If we do so in just Moodle 3.3, then plugins can be more specific (but will limit themselves to PHP 7.0), or they can maintain a separate version for Moodle 3.3 without the type hint.

Will the API be completed by the 25th March 2018 to give plugin developers time to implement it?

We aim to have the fetch side of the API complete by then, but we may encounter additional edge-cases as we go.

We do not anticipate the delete part of the API complete by then. This will be delivered a little late via a separate interface.

Andrew

 
Average of ratings: Useful (2)
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Thank you for your comprehensive reply Andrew,

With "We don't believe that this means things like theme settings. Our primary focus is on the user belonging to actual users rather than administrators.", legally administrators are users that are identifiable as people so therefore would be covered by the GDPR.  Time to ask the Moodle lawyer?

With "These APIs are currently focused on determining where the user has data within Moodle, and then fulfilling their request to obtain a copy of that data. It does so by storing that data in an export. Each plugin must write specific pieces of data to that export." then to be helpful to the concept being communicated to the developer, then how about 'export' instead of 'store' just like the template mechanism (e.g. 'export_for_template' method), then consistent with that concept of output.

If a setting is global like a theme setting and is deemed to be needed for GDPR then that would be the site context?

Kind regards,

Gareth

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Gareth,

Although the setting is entered by an administrator, it is not typically a user preference but a decision made on how to represent the institution.

The question is whether that site setting which defines how the site works can be used to profile a specific user. The setting it intended to allow the site to behave in a particular fashion for all users and describes the system as a whole rather than an individual. Arguably, in the case of a site with only one teacher/administrator, then you could say yes, but I don't believe that this is within the spirit of the law. 

Of course, I am not a lawyer but as an individual I personally do not consider the site configuration of systems that I run to be my personal data.

We will consider renaming the functions. I'll discuss with the rest of the team as to their feelings on this. No-one else has 

And yes, if a setting is global, then it does come under the site context. Of course, if it is a global user preference, then it should be stored using the preference provider instead.

Andrew

 
Average of ratings: -
Picture of Adrian Greeve
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Perhaps one way to consider if information that the administrator has entered should be returned in a data access request is if there is a reasonable expectation that all of this data can now be deleted through the right to be forgotten. Obviously this is not the case with any of the setting configurations. The administrator already has access to all of this information, and removing this information is impracticable to the site continuing to function.

 
Average of ratings: Useful (1)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Gareth,

Further to my previous comment, we have renamed the store functions in both the writer, and the providers. These are now prefixed with export.

Andrew

 
Average of ratings: Useful (1)
Picture of Sander Bangma
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Moodle HQPlugin developers

Hi Gareth,

Thank you very much for your contribution to this thread.  I just wanted to follow up on your question of whether Moodle will provide an ongoing lawyer support line for plugin developers.  

Unfortunately we are currently not in a position to be able to do so.  But rest assured that we have engaged with a EU data privacy lawyer who has provided their expertise and insight as part of the GDPR compliance functionality we are now working on.

As Moodle HQ we are providing institutes and organisations with the tools to assist them to become GDPR compliant, by including new privacy functionality in the Moodle platform.  Each organisation will have to enlist their own support for a detailed assessment of all aspects of data privacy; including systems, policies and procedures outside the Moodle environment.  

Internally Moodle is looking to fill a data privacy role, which will provide advice on Moodle projects and we may from time to time be able to consult them on community matters too, but this will not be the primary purpose of this role.  It is also important to note that legal advisors are only allowed to provide legal advice in those countries where they are formally qualified.  Outside of those countries laws may be interpreted differently and only general guidance can be given.

For the plugin community we will be providing as much assistance as we can, which is why we are now publishing the plugin API in this thread.

All the best,

Sander

 
Average of ratings: Useful (2)
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Thank you for your reply Sander.  Then perhaps as privacy gets more and more important and users as well as developers have questions, then being a community then time for a 'Privacy forum' here upon which people can discuss and have questions answered.

 
Average of ratings: -
Picture of Justin Hunt
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Particularly helpful MoodlersPlugin developers

Andrew,

First of all I am really glad HQ is doing this. It will make life so much easier for plugin devs and Moodle admins in the end. 

In the documentation you state:

There are two types of item to describe the data that you store. These are for:

  • Items in the Moodle database; and

  • Items stored by you in a Moodle subsystem - for example files, and ratings.

What about this case?
The data is stored off site and linked to in Moodle.

In Poodll we store all the files via the files API but we will also be offering cloud storage of those files shortly. And I guess there are other plugins that do this sort of thing too. Would you say that we just consider these items stored in the Database (where the link is), or do we need a third type of item?

 
Average of ratings: Useful (2)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Justin,

As I understand it, in this case, the external system must also be compliant under GDPR and the Moodle administrator must make this known in their site policy which the user must sign. This API is only intended to deal with the Internal storage.

Hope this helps,

Andrew

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi again Justin,

We're looking to add an additional metadata type as you suggest to indicate that a plugin exports data to an external system.

At this point it will just state that it does store externally, but probably won't be able to say where it exports to.

In the case of an activity module like LTI/External Tool, each instance can send to a different endpoint, and in the case of modules like mod_bigbluebutton, you can configure this once within the site, whilst others are a hardcoded location. Fitting the first of these scenarios is the problematic case.

We will also look to integrate the inclusion of this metadata with the new admin tools to help indicate that a plugin does store externally for development of those privacy policies.

Thanks,

Andrew

 
Average of ratings: -
Picture of David Mudrák
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

As per the scenarios we've been working with, all such integrations with 3rd parties are to be listed and described to users as a part of the privacy policy agreements. Users will have to give explicit consent to sharing their personal data with these external systems. Whenever there is any change, a new agreement will be needed prior to using the site.

The personal data shared with the external system must be described to the users so having this covered with the API will be a great benefit.

 
Average of ratings: -
Picture of Neill Magill
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

From my reading of what has been published in the GDPR consent would not always be needed for external 3rd party systems, for example at a University something like Turnitin could be considered a 'legitimate interest' which would not need consent.

Should there be a way for each institution to configure (one time) what the legal basis they are using for the integration? With consent being the only one that a user must explicitly agree to for the data to be shared.

Pretty much everything I have seen is that consent is only for things that are not necessary (i.e. it is almost something that should be the legal basis of last resort)

 
Average of ratings: -
Picture of David Mudrák
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

... consent would not always be needed ...

That is my understanding as well. The Art 6 of GDPR describes cases when processing of personal data is lawful, and explicit consent is just one of them. Still my current reasoning is that even in that case, it is only fair to inform users that such integrations are in place - e.g. as a part of general Privacy Statements or a similar policy document.

 
Average of ratings: -
Picture of Neill Magill
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Yes we defiantly still need to inform them.

I think we possibly needed to be able to give details about the provider such as how they are processing the information for us and contacts such as their data protection officer/person that handles access requests, links to their data handling statements and the like.

I was just concerned by 

Users will have to give explicit consent to sharing their personal data with these external systems. Whenever there is any change, a new agreement will be needed prior to using the site.

I think if we are not using consent we are might be required to inform a user about a change, but should not get a user to agree. I suspect if we ask the user for agreement it might make the basis consent even if we try to say it is not. (which would mean we would need to allow a user to withdraw that consent)

 
Average of ratings: -
Picture of David Mudrák
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Given how the current development evolves, it seems to me it would look like this (at least in the following months / near future):

  • There will be a general system allowing admins to prepare various types of policy documents (site policy, privacy statements, data sharing policy, intellectual right policy etc), have them versioned and agreements with them tracked.
  • Users have to agree to these policies to be able to use the site (or in case of digital minors, their parental guardians will have to provide the consent).
  • It will be up to the institution (admin) how the documents will be worded. You can prepare one document for each 3rd party integration, or a general document listing them all etc.

This way, if you and your legal department are confident that your usage of users personal data is lawful for implicit reasons, you can just have a general privacy policy document where you inform users about such integrations (and reasons for them, retention period and other details). Users will agree with this general policy and done.

Other institutions may prefer / need more detailed setup and I believe that the provided features will allow them to achieve them, too.

We should have a public demo of this available in couple of weeks.

 
Average of ratings: -
Picture of Neill Magill
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Will there be a way to not require users to agree on the Moodle side of things every time, there is a change?

Here I suspect a lot of the details about what we do with data will be handled by a University wide policy, not just one specifically for Moodle. Getting the Moodle report will probably be an excellent way for us to feed into it though to ensure that the University policy covers everything sufficiently.

 
Average of ratings: -
Picture of Michael Aherne
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers
Same here. I think there would have to be a way to disable that as many (most?) institutions will be trying to avoid using consent as the lawful basis for processing unless absolutely necessary. If you're processing data as part of a contract it could get very murky if Moodle were also requiring the student to agree to something explicitly.
 
Average of ratings: -
Picture of David Mudrák
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

You can edit the policy document (e.g. fix a typo or change the formatting). As long as the meaning of the text has not changed from the legal perspective, you do not need to ask users for re-acceptance of the policy (as far as I know).

Again, Moodle does not and will not force you to do anything. We are just trying to equip admins with tools and reports that might be useful. It is up to you to decide on how you implement users' GDPR rights and your GDPR duties.

 
Average of ratings: Useful (1)
Picture of Neill Magill
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Thanks for all the clarifications.

 
Average of ratings: -
Picture of Michael Hughes
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersPlugin developers

Turnitin could fall under a number of options:

* if you consent your users then it can be covered as that (but can be withdrawn, but users can already choose to *not* agree to the TII EULA

* process under legitimate interest, but you (and not Moodle) would need to do a balancing test to ensure that it does fall under legitimate interest

* make it part of the "contract" undertaken between the institution and the student to provide their education.

(based on conversations with our DPO).


M

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Justin and David,

I have now written an external_location. This can be called using the link_external_location and have been documented.

This has been pushed to the repository above.

Thank you for your feedback,

Andrew

 
Average of ratings: -
Picture of Justin Hunt
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Particularly helpful MoodlersPlugin developers

Thats great Andrew. Thanks a lot.  I will play around it.

 
Average of ratings: -
Picture of Valery Fremaux
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Hi Andrew

Here one case study for implementing plugin part of GDPR :

The admin/tool/sync additional plugin provides an "alltogether" set of tools for importing/feeding all essential entities in Moodle. It takes and stores CSV feeding files provided by the administrator to be immediately or later processed by the cron.

The feeder generates feed reports that are backstored in the tool's own file area. So are stored "try-back" files with the failed input lines, in order to fix the misfeedings.

Many of those files, in a less or more strictely speeking way, could hold references to user :

- User account CSV feeds (trivial)

- Cohort CSV feeds (indirect)

- Enrol CSV feeds (indirect)

- UserPictures Zips (direct, the image !)

Those files are stored as archive, or as pre-storage for further execution.

Applicatively, the plugin does not manage user's own data (unless administrator's), but holds a lot of references to normal users.

This could lead to a serious issue if :

- we need to identify where each user has a reference in those files

- we need to delete a single user reference in those files

In a more general approach : How could we deal with all data that are sleeping in caches, temporary folder or fileareas, stored backups ?

 
Average of ratings: -
Picture of Amanda Doughty
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersPlugin developers

Thank you for all of your posts. I also agree that it is great that Moodle HQ are helping plugin developers by implementing this API. Your detailed and thoughtful posts are very much appreciated.

 
Average of ratings: -
Picture of Neill Magill
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Hi Andrew,

How will plugins report what personal data they store via Moodle events?

Would we use link_subsystem and have a single string that defines information about all the events we log, or would we need to describe why we log each event type separately?

Would we also need the ability to describe which events we are listening for and why we process the data in that way?

For example we have a plugin that listens for user_creation events, which would mean that it is processing personal data every time a new user is created.

 
Average of ratings: Useful (1)
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Neill,

I'll get back to you to confirm this, but our feeling is that logs are the property of Moodle as a whole. Moodle will describe the common fields and it will mention assume that the related data will contain user information.

I believe that our intention is to have a Subject Access Request return any log entry where the user is the originator, or is the relateduserid. For the Right to be Forgotten I suspect we will likely remove the relevant log entries.

Where a plugin listen to user events, the existing rules apply - if they stored data, cause data to be stored elsewhere, or export it out of Moodle, then they will need to define that.

I'll confirm with regards logging in the metadata response shortly.

Andrew

 
Average of ratings: -
MoodleFreak
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Plugin developers

​Good to see that Moodle is working on the GDPR. And that the system admin & developers will not be left in the dark.

Is there already an example of a block or mod that uses this implementation? When can we expect that this Google document is final?

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Luuk,

Please see MDL-61306 - this is the epic in which we are carrying out all of this work.

We have so far configured a number of blocks, all core themes, an admin tool, some activity modules and others are in-progress, and a number of other Moodle components.

The document is, for all intent and purpose, final. The only changes to be made to it are corrections, clarifications, and additional examples.

Andrew

 
Average of ratings: -
MoodleFreak
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Plugin developers

@Andrew, thanks for your response.

 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Hi Andrew,

In the document there is some good examples and implementation for 'User preferences' away from contexts but the 'deletion' element seems to be context based only.  Will there be specific user preference methods for such?  Please see: https://docs.google.com/document/d/1Y7n4Qkez4Tl83rWArOQPQCpE2NeSA2bUa8gOR2r_JFE/edit?disco=AAAABt0mJ2E

Kind regards,

Gareth

 
Average of ratings: -
Picture of Andrew Nicols
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersMoodle HQParticularly helpful MoodlersPlugin developersTesters

Hi Gareth,

Technically speaking, user preferences are a system-wide thing.

A standard user_preference_provider will only have to define itself in the metadata, and return its value in export_user_preferences. We will handle removal of the user preference at the core level if the user chooses to be forgotten.

If you are using the preferences table to store information for a specific context/plugin then you will also have to implement the plugin/provider and have the get_contexts_for_userid function return any of the affected contexts. You can leave the export_user_data function empty since the preference will be exported by the user_preference_provider.

Note however that it is not possible to export user preferences for anywhere except the system context.

We have not encountered anywhere that preferences are used to store information for a specific context (the system is not designed for this) so if you are aware of any, we may need to remove this limitation in the May 14th release.

Andrew

p.s. thank you for posting this question here - it would be better to keep all of these questions in the forum thread for persistence and context.

 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Hi Andrew,

Thank you for your useful reply.

The plugin I'm talking about is Collapsed Topics (CT) where (like your user tour example) I append an id to the user preference.  In CT that id is the course id as I know that id when the course loads and hence can get the user preference for the user.  Technically I am using user preferences and the 'course context' is not technically specific but conceptual, so could stick to the pure 'site' example as you say "Note however that it is not possible to export user preferences for anywhere except the system context." and thus I would be exporting for the course context - will this break the API?

But I can see how 'get_contexts_for_userid' could be useful as it would tell the user which courses they were using are in the CT format and had the toggle state stored - there are settings to turn it off.

Humm, that then leads to a question of what should happen if the setting to turn it off is turned off, I should probably delete all user preferences pertaining to CT.  Food for thought.

Cheers,

Gareth

 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

P.S. Please could you tell me how I can test my code (not PHP Unit test) via running a 'use case scenario' through with the UI on M3.4.2?  So how can a user request their data such that it invokes the code I've written in provider.php and I can see what happens.

 
Average of ratings: Useful (1)
Picture of Michael Hughes
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersPlugin developers

I've thrown together a cli script to "fake" a SAR request, approve it and execute the process_data_request_task() call.

I stuck in in /admin/tool/dataprivacy/cli for the moment.

Otherwise it's really slow to manually re-create an SAR, and I think I had issues with file generation/writing when I "persuaded" the code to never mark the SAR complete so I could re-use an existing request via the cron.

Note this has a DEBUG_DEVELOPER on requirement!

Michael

 
Average of ratings: Useful (4)
Picture of Michael Hughes
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersPlugin developers

I've put the code for this on a gist, as I've made a few enhancements: 

https://gist.github.com/mhughes2k/ede8db9739b5faed55203902b536a3cb


 
Average of ratings: Useful (5)
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Thank you Michael,

I'm getting a:

!!! Exception - Class 'tool_dataprivacy\data_request' not found !!!
!!

On M3.4.2 as don't appear to have a '/admin/tool/dataprivacy' folder.  I can't find it on MOODLE_34_STABLE or master branches.

Ah ha, is this it: https://github.com/moodlehq/moodle-tool_dataprivacy ?

Kind regards,

Gareth

 
Average of ratings: Useful (1)
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Interesting.  Using the tool and the cli script I get no user preferences?  Is this the tool or the API or me?  Ref: https://github.com/gjb2048/moodle-format_topcoll/blob/master/classes/privacy/provider.php - but surely there should be other user preferences?

 
Average of ratings: -
Photo of Jan
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 
Average of ratings: -
Gareth J Barnard
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 
Average of ratings: -
Photo of Jan
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developers

Sorry, I was mistaken.

Function or constant names that do not contain a backslash like name can be resolved in 2 different ways.
First, the current namespace name is prepended to name.
Finally, if the constant or function name does not exist in the current namespace, a global constant or function name is used if it exists.

(http://php.net/manual/en/language.namespaces.faq.php#language.namespaces.faq.shortname2)

So your call to get_user_preferences should be fine. Are you sure your provider was invoked? What does it yield if you add var_dump($preferences) after https://github.com/gjb2048/moodle-format_topcoll/blob/f546c09902979a669587dc0e6fbb985f5956ab42/classes/privacy/provider.php#L67 ?

 
Average of ratings: -
Picture of Valery Fremaux
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
 

Trying to update my first significant plugin (quite simple) and some practical questions arise about exporting data, not clear to me in documentation :

- if there is no significant substructure ? should it be passed a null or an empty array to $subcontext  ?

- for $data as a class and some user attached information in a table, should the full record being returned (including technical foreign keys) or just the "user data of interest" ?

If i understood correctly the API : writers receive a list of context ids and should build the path back to the internal implementation to find the data record. the get_contexts_for_userid collects contexts, OK. The export_user_data gets the data for the user. It receives an approved contextlist in which we can get the user identity back ($contextlist->get_user()) for pointing the specific user's data.

What if the user's data has internally several items for the same context. How to aggregate them ? Is the subcontext suitable for this purpose ?

Could we have one example of a sufficiantly complex subcontext case to figure out ?

Thanks !


 
Average of ratings: -
Picture of Justin Hunt
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Particularly helpful MoodlersPlugin developers

I spent a good part of today looking over the docs, using the request tool, and exporting data from mod_choice and block_html.  I was hoping to get stuck into implementing the privacy apis in Poodll and other plugins. But some key parts of what needs to be done are still unclear. 

These two classes look like a good place to start because mod_choice and block_html both use them.

use \core_privacy\local\request\writer;
use \core_privacy\local\request\helper;
 But both classes as implemented in master branch are geared towards the 'block' and 'mod' plugin types. In my case I also need to work with assignment submission, assignment feedback and question types. And I need to work specifically with files. 


Regarding Assignment submissions and feedback

Since these are subplugins, we are supposed to look at the contract produced by the parent plugin. Thats not implemented yet as far as I can tell.

Regarding files.
File export /delete is not implemented yet in helper and writer, even for block or mod plugins. So I think I need to just use the helper functions as described in the docs and hope. Right? {edit: actually rereading the docs ... it looks like I might just be looking in the wrong place for the implementation. I should have looked at moodle_content_writer where it is implemented. }

My real question is, since I know that all the core plugins will need to implement these things, is it worth trying to figure it out now? Or should I just wait a few weeks for more code samples to become available? Or is there a treasure trove of code available, and I am looking in the wrong place?

 
Average of ratings: Useful (1)
Picture of David Mudrák
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersMoodle HQParticularly helpful MoodlersPlugin developersPlugins guardiansTestersTranslators

Please note you may be interested in watching issues in the MDL-61306 epic, such as MDL-61918 Implement core_privacy for assignment plugins that is waiting for integration review. Implementations are supposed to land frequently in following two or three weeks.

 
Average of ratings: Useful (3)
Picture of Justin Hunt
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Particularly helpful MoodlersPlugin developers

Thanks David. That helps. 

I could see the upcoming mod_assign code here. 

https://github.com/abgreeve/moodle/tree/wip-MDL-61308-master/mod/assign

I can wait till its properly integrated, but this gives me a good understanding of the scope of what I need to do, and I can get ready for it.

 
Average of ratings: -
Picture of Justin Hunt
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Particularly helpful MoodlersPlugin developers

What was decided about question types ultimately? Can we leave it up to the quiz to handle question type privacy reporting and actions? Or do we need to do something?

 I can not see any implementations of the privacy API in core question types, and the Plugin privacy registry tool flags them all as "unimplemented."

It would make my day to not have to do anything at all for my question types. Sounds too good to be true though ...  

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersDocumentation writersParticularly helpful MoodlersPlugin developers

Privacy implementation for question types is going through integration now (MDL-61407).

In the end, Andrew Nicols managed to handle everything in core, so question types just need to implement the null provider.

 
Average of ratings: Useful (2)
Picture of Justin Hunt
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Particularly helpful MoodlersPlugin developers

Fantastic. Thanks @Andrew and @Tim

 
Average of ratings: -
Picture of Marcus Green
Re: GDPR and Privacy - What it means to be plugin developers. Urgent request for comments
Core developersParticularly helpful MoodlersPlugin developersTesters

Thanks chaps, that answered a question for me as well.

 
Average of ratings: -