Missing privacy api

[danmarsden]

Moodle uses a privacy API for GDPR compliance to allow plugins to specify how they deal with user data. Your plugin stores user data in a number of tables which will need to be included in the privacy api classes.

Sites that use continuous integration processes will not be able to use your plugin because Moodle runs unit tests which check to see if all extra plugins include the privacy class.

More information on the privacy class is here: https://moodledev.io/docs/apis/subsystems/privacy#

I'm not quite clear if your plugin integrates with an external system or if it stores all the data within Moodle ... If it does integrate with an external system this issue is a blocker for plugins db approval.

[danmarsden]

looks like the plugin passes data to an external LRS so this is definitely a blocker for plugins db approval - please also note that on top of implementing the normal privacy api covering your tables with export and delete functions, you will also need to add the external_link_location api to clearly state what user data is passed to the external api.

[ADLMeganBohland]

@danmarsden Thank you for the link Dan. I will study and implement, I guess because my tables only stored data like the userid I didn't consider that as personal information such as a name or address for example. Although reading the info on the privacy API I se where they point out how the id could be used to trace back to user. Also the way the LRS is communicated with is also with an ID or unique registration code. So if I implement the privacy class this should address the concerns?

[danmarsden]

yeah - any tables with a userid field are classed as user data - the unit tests in Moodle pick that up too and will throw errors if it finds a table with a userid that is not included in the privacy api.

If "user data" is passed to the LRS - eg learning records that are associated with the user - that just needs to be "documented" using the external_link_location part - so that a privacy officer can view the reports in Moodle and understand what information is stored outside the system.

[ADLMeganBohland]

@danmarsden Hey Dan, I was watching some of the Moodle videos on this GDPR rule. Do we need to implement this whole consent system they have? I saw one were it has pages of 'what we do with data' etc. Essentially there are no user entering fields, I imagine the only things that will belong to them are their user ids and grades. So for instance, does their need to be a 'consent' form to grade? Sorry I know you are not a lawyer, but have you seen similar plugins?

[danmarsden]

nah - ignore all the consent stuff, the main thing you need to look at is the privacy class itself - once you have implemented that it means an end user can request any personal information stored within Moodle that is attached to them, and they can also request the deletion of that data as well - "consent" to store information by your plugin is really covered already by the main site policies that an organisation can put into place if they want to.

I find it useful looking at other plugins privacy classes first you need to add the details of the tables that include user fields in the get_metadata() function: https://moodledev.io/docs/apis/subsystems/privacy#describing-data-stored-in-database-tables

(that parts pretty easy)

then you need to add the functions for exporting and deleting user data - which is a bit more complex but if you look at the other moodle activity plugins you will hopefully see some structures/ examples you can borrow from.

[ADLMeganBohland]

Hi Dan, sorry for the delay. I have been working on this, but I'm struggling. I can get the export to work and it deletes most data, but it won't delete the records in my three tables such as grades. I tried running

        $sql = array("moodlecourseid" => $instanceid, "userid" => $userid);
        $record = $DB->delete_records($table, $sql);  

in the delete_data_for_user() function. But what's really odd is the contextlist moodle passes to this functiuon seems off by 1, for instance it shows the course_module instance as 121, when it should be 122. Where does moodle get the context info from? And for some users it doesn't even seem to create a context. Can you point me toward any examples or forums this is touched on?

This is the full function in the provider.php file: public static function delete_data_for_user(approved_contextlist $contextlist) {

    global $DB;

    if (empty($contextlist->count())) {
        return;
    }
    $userid = $contextlist->get_user()->id;

    foreach ($contextlist->get_contexts() as $context) {

        $instanceid = $DB->get_field('course_modules', 'instance', ['id' => $context->instanceid], MUST_EXIST);

    // Tables to delete from with same key if context matches.
    $tables = ['cmi5launch_usercourse', 'cmi5launch_sessions', 'cmi5launch_aus'];

    foreach ($tables as $table) {

        $sql = array("moodlecourseid" => $instanceid, "userid" => $userid);

        $record = $DB->delete_records($table, $sql);

    }
}

Again it seems to work mostly, it deletes the user from Moodle contexts, just not the plugin tables, which I am attempting to do to be GDPR compliant. Any thoughts?

[danmarsden]

Hey! - I wish I had time to help further but unfortunately I haven't got time to dig into this as a volunteer for you - if you're still stuck you could try asking in the moodle community forums and point to your code and someone else might have time to chime in and help!

[ADLMeganBohland]

Ok, will do. Thanks!

[ADLMeganBohland]

Hi @danmarsden, I figured out and finished the implementation of the privacy API in branch 7c07884