1=head1 General Data Protection Regulation (GDPR) Support in RT 2 3The General Data Protection Regulation (GDPR) is a new set of regulations passed by the European 4Union taking effect on 25 May 2018. You can read more about the new regulations on 5the L<GDPR website|https://ec.europa.eu/info/law/law-topic/data-protection_en>. 6 7Many of these regulations fall to the web site owner or provider of a service, so they are outside 8the scope of a software solution. However, RT provides some features that make 9compliance easier for organizations who run RT, whatever your internal GDPR policies 10might be. 11 12=head1 Viewing User Data in RT 13 14One of the GDPR provisions asserts a "right of access" for users, meaning they can request 15access to the personal data an organization has stored for them. Core user data in RT, like 16name and email address, are typically stored on a user record. 17There are different options to manage how different classes of RT users can view 18and even edit their user information. 19 20=head2 Privileged Users 21 22Privileged users in RT are typically the staff of an organization, so they likely have access 23to their information in RT. If given the ModifySelf right, Privileged users can 24see and modify their full user record at Logged in as > Settings > About Me. 25 26=head2 Unprivileged Users 27 28Unprivileged users will interact with RT via the Self Service interface or through email only. 29These users are typically customers and will have much less default access in RT. Since there 30are many different relationships with end users, RT offers several different options to 31allow Self Service users to view and edit their user data. All of the options below except 32C<view-info> also require users to have the ModifySelf right. 33 34For C<view-info> and C<edit-prefs-view-info>, self service users can't update 35their user information directly, but you can provide an easy way for them 36to request an update. If you set L<RT_Config/SelfServiceRequestUpdateQueue> to 37the name of an RT queue, a quick create portlet will appear on the self service 38Preferences page. Users can then easily create a ticket to request updates to 39their user information. 40 41Note that self service users must have the CreateTicket right on the queue you 42select to allow them to create the new request. 43 44L<RT_Config/SelfServiceUserPrefs> has the following options: 45 46=over 47 48=item C<edit-prefs> (default) 49 50When set to C<edit-prefs>, self service users will be able to update 51their Timezone and Language preference and update their password. 52This is the default behavior of RT. 53 54=item C<view-info> 55 56When set to C<view-info>, users will have full access to all their 57user information stored in RT on a read-only page. 58 59=item C<edit-prefs-view-info> 60 61When set to C<edit-prefs-view-info>, users will have full access as in 62the C<view-info> option, but also will be able to update their Language 63and password as in the default C<edit-prefs> option. 64 65=item C<full-edit> 66 67When set to C<full-edit>, users will be able to fully view and update 68all of their stored RT user information. 69 70=back 71 72=head1 Downloading User Data 73 74To provide RT administrators a way to give end users a copy of their data on 75request, RT provides several different options to download user data to format-neutral 76tsv files. Access to these downloads are available for admins and can also 77be offered through self service. 78 79For RT administrators, user data downloads are available on the user admin 80page at Admin > Users > Select > [find a user]. 81 82To offer download to users via self service, enable the option 83L<RT_Config/SelfServiceDownloadUserData> and grant the ModifySelf right 84to unprivileged users. 85 86=head2 Download Core User Data 87 88This option provides a file with basic user information from RT. The 89format of the download can be modified by setting L<RT_Config/UserDataResultFormat>. 90 91=head2 Download User Tickets 92 93This option provides a file with ticket summaries for all tickets that have 94the selected user as a requestor. The ticket summary file format can be 95configured with L<RT_Config/UserTicketDataResultFormat>. 96 97=head2 Download User Transactions 98 99This option provides transaction summaries for all transactions on which the 100selected user is the creator. This will typically be all of the correspondence 101where they replied back to a ticket, so it contains their part of ticket 102conversations. The format can be configured with L<RT_Config/UserTransactionDataResultFormat>. 103 104=head1 Removing User Data 105 106One provision of GDPR gives users the "right to be forgotten" which means they can 107request that their data be removed from an organization's system. RT provides several 108options to remove data associated with a user. These use the L<RT::Shredder> tool and 109links are provided from the user administration page to make removal easier. 110 111=head2 Anonymize User 112 113This option will clear all data on the user record for the current user, 114while preserving the user record. The required fields for a user are set 115to anonymous values. 116 117This option leaves all tickets intact, but the personal information, like 118email address, stored on the user record is removed. 119 120It is important to note that this action will not remove user information 121from ticket message bodies or email headers, only data from any RT-based sections like 122People. To anonymize ticket data, RT provides a script L<rt-munge-attachments> 123which you should also run. It is not linked from the web UI because it can 124require a long time to run. 125 126=head2 Replace User Information 127 128This option uses shredder with the replace_relations option to replace the 129existing userid with the RT user "Nobody" in transactions and other records 130that have the id. The user record is then deleted. This option is likely the 131easiest since it automatically handles linked objects in one step. 132 133As with the Anonymize User option, this shredder configuration does not find 134references to email address or other data in the body of correspondence. 135RT provides a script L<rt-munge-attachments> which you should also run to replace 136or remove these references. 137 138To replace with a user other than Nobody, update the replace_relations argument 139on the shredder page before running. 140 141=head2 Remove User Information 142 143This option uses shredder to remove the user record by running shredder 144without the replace_relations option. Note that this option will fail if 145it finds remaining references to the user. For example, if the user is a 146requestor on a ticket and the ticket is still in the system, the user 147will still be connected to the ticket, transactions on the ticket, etc. 148 149To resolve this, you can use other shredder plugins to first remove the other 150associated objects. For tickets, for example, you could run a search for 151"Requestor.EmailAddress = 'user1@example.com'" and then shred the tickets returned. 152Once the associated objects are shredded, you can try shredding the user again. 153See L<RT::Shredder> for information on plugins for other objects. 154 155=cut 156