 Hi, I'm Andrew Nichols and I'm a senior analyst, developer and integrator here at Moodle HQ. This screencast will cover the changes that you, as a plugin developer, need to make your plugin for the General Data Protection Regulation and the introduction of the new Privacy API in Moodle 3.3, 3.4 and 3.5. As you may be aware, the new European General Data Protection Regulation comes into effect on the 25th of May 2018. These regulations cover the collection, use and storage of personal data for all EU citizens. It aims to harmonise data privacy laws and to set new standards for data privacy, empowering individuals with the control that they need over their personal data. It applies worldwide to organisations outside of the EU which collect any personal data on any EU resident. To help organisations that become compliant with the new regulation, we at Moodle have created a new Privacy API and a collection of tools for data protection officers. This screencast will discuss the Privacy API and what you, as a plugin developer, will need to do in order to make your plugins work with the new API. The changes for the API are covered in the Moodle Tracker issue number MDL 61306. The API is also documented in the Moodle Developer documentation with a collection of FAQs and an active forum discussion on the General Developer Forum. This API is available for Moodle 3.3.5, Moodle 3.4.2 and Moodle 3.5.0. In order to implement the new Privacy API, your plugin must write a Privacy Provider class. This class will be located within your plugins code at classes slash privacy slash provider dot PHP. The API makes use of PHP namespaces to auto load your provider and your provider must implement one or more of the Privacy PHP interfaces. Even if you don't store any personal data, you still have to do something. There are two types of provider. There are metadata providers and request providers. The metadata providers allow you to describe the personal data that you store. The request providers allow you to export and delete the personal data that you store. And when data is exported, we do so using a Privacy Writer. Even if you don't store any user data, you need to tell us that you don't store any data. When you do so, you can implement a special metadata interface called a null provider. The null provider just asks that you provide a reason to tell us why you are able to implement the null provider. This is done through use of a language string identifier and a corresponding language string in your plugin's language file. For those plugins which do store data, you must describe what data that you store. We ask that you declare and describe any database table which contains personal user data, any external system that you send such data to, any plugins which you send data to and any other core subsystem that you send data to. Again, we make use of language strings here so that these descriptions and the summaries of these tables can be translated. Users can make a request via the new data privacy tool. There are two types of request that they can make, a request to export their data and a request to invoke their right to be forgotten. After a request has been made by a user, your plugin will be asked to identify which Moodle context it stores that data in. Although your plugin may have more granular information about where a user has data, the context is the smallest piece of shared information that can be universally used across Moodle. Your plugin must identify each context where the specified user has any data. We do this using SQL rather than a set of API calls to try and avoid heavy processing in order to just define context information. Results are returned within a context list. You can also call the add from SQL function as many times as you like, but we would really recommend that the number of queries be kept to a minimum wherever possible. After all plugins have polled for that context list, the data is presented to the Data Protection Officer for confirmation. At the moment we just allow for an approval or denial of that request. In certain circumstances, some contexts may be removed from that context list. Although the GDPR does provide the right to be forgotten, this right is not absolute. The GDPR does allow for some data to be held for longer, even after a user has requested to be forgotten. After the Data Protection Officer has approved the user request, the privacy API will call your plugin again, this time providing an approved context list. This lists the number of contexts and which contexts have been included in the request. The approved context list class includes a number of helper functions to help you to iterate over those contexts, and it also includes helper functions for the user record for the user who made the request. In the case of subject access requests where data is exported, the export user data function will be run as the user who made the request. You must export any relevant data that you hold for each of the supplied contexts in the list. Exporting is performed using the writer, and all data is written to a specific context. There are several writer functions to use, and the functions that you will need will depend on the kind of data that you store and how you store it. In most cases, you will want the export data and export user files functions. You may also need to export additional metadata, related files, or maybe files in a custom format. If your plugin stores user preferences, then you will need to implement the user preference provider. Users can also request to be forgotten. Again, this is handled using the approved context list. You should only delete data from the context described in this approved context list. In some cases, you will not be able to delete all data. For example, if a teacher asks to be forgotten, then you probably should not delete the grades and feedback that they have awarded to another user. The GDPR also encourages privacy by design, and personal data will be remarked for removal when it is no longer required. This time period is set by the Data Protection Officer on a per-context basis from within the Privacy Tool. When implementing this part of the interface, you will be passed a single context and should remove all user data that you store or have caused to be stored for this context. You should not delete the actual plugin instance, only the data that is stored within it. Once the request has been completed and all data has been collected, it will be made available to the user. We are aware that many plugin developers prefer to have one branch of their code for all versions of Moodle. When we wrote to the Privacy API, we decided to use a number of PHP 7 features, such as the return type declaration and scalar type hints. Since Moodle 3.3 still supports PHP version 5.6, these can't be used universally. To help with this, we have written a legacy polyfill. The Moodle documentation has more information on how to use this polyfill, but this example may give you some help. We highly recommend writing good unit tests for your code. Unit tests included in the core Privacy API itself will already test any plugin which is a null provider, as well as checking that all strings specified in your metadata are present. We have also written a Privacy provider test case, which provides several helper functions, and a version of the writer which can be queried and information can be fetched and checked after being exported. Thank you for watching. If you have any further questions, please hop on over to the general developer forums or join us on our Telegram developer chat.