The General Data Protection Regulation (GDPR) is a new set of regulations passed by the European Union taking effect on 25 May 2018. You can read more about the new regulations on the GDPR website.
Many of these regulations fall to the web site owner or provider of a service, so they are outside the scope of a software solution. However, RT provides some features that make compliance easier for organizations who run RT, whatever your internal GDPR policies might be.
One of the GDPR provisions asserts a "right of access" for users, meaning they can request access to the personal data an organization has stored for them. Core user data in RT, like name and email address, are typically stored on a user record. There are different options to manage how different classes of RT users can view and even edit their user information.
Privileged users in RT are typically the staff of an organization, so they likely have access to their information in RT. If given the ModifySelf right, Privileged users can see and modify their full user record at Logged in as > Settings > About Me.
Unprivileged users will interact with RT via the Self Service interface or through email only. These users are typically customers and will have much less default access in RT. Since there are many different relationships with end users, RT offers several different options to allow Self Service users to view and edit their user data. All of the options below except view-info also require users to have the ModifySelf right.
For view-info and edit-prefs-view-info, self service users can't update their user information directly, but you can provide an easy way for them to request an update. If you set "SelfServiceRequestUpdateQueue" in RT_Config to the name of an RT queue, a quick create portlet will appear on the self service Preferences page. Users can then easily create a ticket to request updates to their user information.
Note that self service users must have the CreateTicket right on the queue you select to allow them to create the new request.
"SelfServiceUserPrefs" in RT_Config has the following options:
edit-prefs (default)When set to edit-prefs, self service users will be able to update their Timezone and Language preference and update their password. This is the default behavior of RT.
view-infoWhen set to view-info, users will have full access to all their user information stored in RT on a read-only page.
edit-prefs-view-infoWhen set to edit-prefs-view-info, users will have full access as in the view-info option, but also will be able to update their Language and password as in the default edit-prefs option.
full-editWhen set to full-edit, users will be able to fully view and update all of their stored RT user information.
To provide RT administrators a way to give end users a copy of their data on request, RT provides several different options to download user data to format-neutral tsv files. Access to these downloads are available for admins and can also be offered through self service.
For RT administrators, user data downloads are available on the user admin page at Admin > Users > Select > [find a user].
To offer download to users via self service, enable the option "SelfServiceDownloadUserData" in RT_Config and grant the ModifySelf right to unprivileged users.
This option provides a file with basic user information from RT. The format of the download can be modified by setting "UserDataResultFormat" in RT_Config.
This option provides a file with ticket summaries for all tickets that have the selected user as a requestor. The ticket summary file format can be configured with "UserTicketDataResultFormat" in RT_Config.
This option provides transaction summaries for all transactions on which the selected user is the creator. This will typically be all of the correspondence where they replied back to a ticket, so it contains their part of ticket conversations. The format can be configured with "UserTransactionDataResultFormat" in RT_Config.
One provision of GDPR gives users the "right to be forgotten" which means they can request that their data be removed from an organization's system. RT provides several options to remove data associated with a user. These use the RT::Shredder tool and links are provided from the user administration page to make removal easier.
This option will clear all data on the user record for the current user, while preserving the user record. The required fields for a user are set to anonymous values.
This option leaves all tickets intact, but the personal information, like email address, stored on the user record is removed.
It is important to note that this action will not remove user information from ticket message bodies or email headers, only data from any RT-based sections like People. To anonymize ticket data, RT provides a script rt-munge-attachments which you should also run. It is not linked from the web UI because it can require a long time to run.
This option uses shredder with the replace_relations option to replace the existing userid with the RT user "Nobody" in transactions and other records that have the id. The user record is then deleted. This option is likely the easiest since it automatically handles linked objects in one step.
As with the Anonymize User option, this shredder configuration does not find references to email address or other data in the body of correspondence. RT provides a script rt-munge-attachments which you should also run to replace or remove these references.
To replace with a user other than Nobody, update the replace_relations argument on the shredder page before running.
This option uses shredder to remove the user record by running shredder without the replace_relations option. Note that this option will fail if it finds remaining references to the user. For example, if the user is a requestor on a ticket and the ticket is still in the system, the user will still be connected to the ticket, transactions on the ticket, etc.
To resolve this, you can use other shredder plugins to first remove the other associated objects. For tickets, for example, you could run a search for "Requestor.EmailAddress = 'user1@example.com'" and then shred the tickets returned. Once the associated objects are shredded, you can try shredding the user again. See RT::Shredder for information on plugins for other objects.
← Back to index