[Rt-commit] rt branch, 4.4-trunk, updated. rt-4.4.3-178-g1fb112a18

? sunnavy sunnavy at bestpractical.com
Fri Jan 4 13:10:34 EST 2019

The branch, 4.4-trunk has been updated
       via  1fb112a1894ab9f111fd65fc334c6f257b2b8bfa (commit)
       via  97ec9cb7cbe2f39b8d5954fb54cca9ba0d81fc51 (commit)
       via  bea4ff28a1d971ce9ef1e852f39e5ed41c6003c1 (commit)
      from  fe7e099639824086428fe6d6db2e2a7ddba8ee0d (commit)

Summary of changes:
 docs/GDPR.pod                | 145 +++++++++++++++++++++++++++++++++++++++++++
 sbin/rt-munge-attachments.in |  30 ++++++---
 2 files changed, 165 insertions(+), 10 deletions(-)
 create mode 100644 docs/GDPR.pod

- Log -----------------------------------------------------------------
commit bea4ff28a1d971ce9ef1e852f39e5ed41c6003c1
Author: Jim Brandt <jbrandt at bestpractical.com>
Date:   Thu Dec 20 16:11:26 2018 -0500

    Add GDPR docs

diff --git a/docs/GDPR.pod b/docs/GDPR.pod
new file mode 100644
index 000000000..41ffa6563
--- /dev/null
+++ b/docs/GDPR.pod
@@ -0,0 +1,145 @@
+=head1 General Data Protection Regulation (GDPR) Support in RT
+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 L<GDPR website|https://ec.europa.eu/info/law/law-topic/data-protection_en>.
+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.
+=head1 Viewing User Data in RT
+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.
+=head2 Privileged Users
+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.
+=head2 Unprivileged Users
+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 also
+require the users to have the ModifySelf right.
+L<RT_Config/SelfServiceUserPrefs> has the following options:
+=item C<edit-prefs> (default)
+When set to C<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.
+=item C<view-info>
+When set to C<view-info>, users will have full access to all their
+user information stored in RT on a read-only page.
+=item C<edit-prefs-view-info>
+When set to C<edit-prefs-view-info>, users will have full access as in
+the C<view-info> option, but also will be able to update their Language
+and password as in the default C<edit-prefs> option.
+=item C<full-edit>
+When set to C<full-edit>, users will be able to fully view and update
+all of their stored RT user information.
+=head1 Downloading User Data
+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
+L<RT_Config/SelfServiceDownloadUserData> and grant the ModifySelf right
+to unprivileged users.
+=head2 Download Core User Data
+This option provides a file with basic user information from RT. The
+format of the download can be modified by setting L<RT_Config/UserDataResultFormat>.
+=head2 Download User Tickets
+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 L<RT_Config/UserTicketDataResultFormat>.
+=head2 Download User Transactions
+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 L<RT_Config/UserTransactionDataResultFormat>.
+=head1 Removing User Data
+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 L<RT::Shredder> tool and
+links are provided from the user administration page to make removal easier.
+=head2 Anonymize User
+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 L<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.
+=head2 Replace User Information
+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 L<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.
+=head2 Remove User Information
+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 at example.com'" and then shred the tickets returned.
+Once the associated objects are shredded, you can try shredding the user again.
+See L<RT::Shredder> for information on plugins for other objects.

commit 97ec9cb7cbe2f39b8d5954fb54cca9ba0d81fc51
Author: Jim Brandt <jbrandt at bestpractical.com>
Date:   Wed Jan 2 16:17:03 2019 -0500

    Refine rt-munge-attachments docs clarifying GDPR cases

diff --git a/sbin/rt-munge-attachments.in b/sbin/rt-munge-attachments.in
index 2a3eec969..ad7cc0d87 100644
--- a/sbin/rt-munge-attachments.in
+++ b/sbin/rt-munge-attachments.in
@@ -92,32 +92,42 @@ print STDERR $msg . "\n";
 =head1 rt-munge-attachments
-rt-munge-attachments - Remove or replace string from attachments table.
+rt-munge-attachments - Remove or replace strings in attachment records
 =head1 SYNOPSIS
-    rt-munge-attachments --search="user1 at example.com" --replace="Ex-Employee"
+    rt-munge-attachments --search="user1 at example.com" --replace="removed-user at example.com"
-When a match is found in the Headers column, the header is deleted unless a replacement
-value was provided. If a match is found in the Content column then the matching substring
-will be replaced with a blank or provided value.
+In RT, "attachments" contain all correspondence on tickets, not just file-based
+attachments. Although attachments are normally not modified by RT once created,
+this script provides a way to change or remove personalized data like email
+addresses that might be contained in the headers or bodies of RT attachment
+records. This allows admins to comply with GDPR regulations, but retain ticket
+histories with remaining non-personal information.
+A transaction is recorded when this script modifies content so there is a record that
+something was changed on the ticket. Details of the change are not recorded since
+the values would likely contain personal information which the script was run to
+If modifying ticket history violates audit policies, admins should not use this
 =head1 OPTIONS
-=over 2
 =item --search=SEARCH
-Provide a string to search the header and content columns in the attachments table, if a match
-is found the content will be removed.
+Provide a string to search the header and content columns in the attachments table.
+If a match is found the content will be removed unless a replacement is provided.
 =item --replace=REPLACEMENT
-Provide a string to replace strings matching the search string for the
-attachments table.
+Provide a string to replace the value matched by the search.

commit 1fb112a1894ab9f111fd65fc334c6f257b2b8bfa
Merge: fe7e09963 97ec9cb7c
Author: sunnavy <sunnavy at bestpractical.com>
Date:   Sat Jan 5 02:08:36 2019 +0800

    Merge branch '4.4/add-gdpr-docs' into 4.4-trunk


More information about the rt-commit mailing list