docs/php/gdpr.md

   1 # General Data Protection Regulation (GDPR)
   2
   3 ## Introduction
   4
   5 The General Data Protection Regulation (GDPR) of the European Union enters into
   6 force on May 25, 2018. It comes with a set of restrictions when handling users'
   7 personal data as well as to provide an interface to export this data on demand.
   8
   9 If you're looking for a guide on the implications of the GDPR and what you will
  10 need or consider to do, please read the article [Implementation of the GDPR](https://www.woltlab.com/article/106-implementation-of-the-gdpr/)
  11 on woltlab.com.
  12
  13 ## Including Data in the Export
  14
  15 The `wcf\acp\action\UserExportGdprAction` introduced with WoltLab Suite 3.1.3
  16 already includes the Core itself as well as all official apps, but you'll need to
  17 include any personal data stored for your plugin or app by yourself.
  18
  19 The event `export` is fired before any data is sent out, but after any Core data
  20 has been dumped to the `$data` property.
  21
  22 ### Example code
  23
  24 {jinja{ codebox(
  25   title="files/lib/system/event/listener/MyUserExportGdprActionListener.class.php",
  26   language="php",
  27   filepath="php/gdpr/MyUserExportGdprActionListener.class.php"
  28 ) }}
  29
  30 ### `$data`
  31
  32 Contains the entire data that will be included in the exported JSON file, some
  33 fields may already exist (such as `'com.woltlab.wcf'`) and while you may add or
  34 edit any fields within, you should restrict yourself to only append data from
  35 your plugin or app.
  36
  37 ### `$exportUserProperties`
  38
  39 Only a whitelist of  columns in `wcfN_user` is exported by default, if your plugin
  40 or app adds one or more columns to this table that do hold personal data, then
  41 you will have to append it to this array. The listed properties will always be
  42 included regardless of their content.
  43
  44 ### `$exportUserPropertiesIfNotEmpty`
  45
  46 Only a whitelist of  columns in `wcfN_user` is exported by default, if your plugin
  47 or app adds one or more columns to this table that do hold personal data, then
  48 you will have to append it to this array. Empty values will not be added to the
  49 output.
  50
  51 ### `$exportUserOptionSettings`
  52
  53 Any user option that exists within a `settings.*` category is automatically
  54 excluded from the export, with the notable exception of the `timezone` option.
  55 You can opt-in to include your setting by appending to this array, if it contains
  56 any personal data. The listed settings are always included regardless of their
  57 content.
  58
  59 ### `$exportUserOptionSettingsIfNotEmpty`
  60
  61 Any user option that exists within a `settings.*` category is automatically
  62 excluded from the export, with the notable exception of the `timezone` option.
  63 You can opt-in to include your setting by appending to this array, if it contains
  64 any personal data.
  65
  66 ### `$ipAddresses`
  67
  68 List of database table names per package identifier that contain ip addresses.
  69 The contained ip addresses will be exported when the ip logging module is enabled.
  70
  71 It expects the database table to use the column names `ipAddress`, `time` and
  72 `userID`. If your table does not match this pattern for whatever reason, you'll
  73 need to manually probe for `LOG_IP_ADDRESS` and then call `exportIpAddresses()`
  74 to retrieve the list. Afterwards you are responsible to append these ip addresses
  75 to the `$data` array to have it exported.
  76
  77 ### `$skipUserOptions`
  78
  79 All user options are included in the export by default, unless they start with
  80 `can*` or `admin*`, or are blacklisted using this array. You should append any
  81 of your plugin's or app's user option that should not be exported, for example
  82 because it does not contain personal data, such as internal data.