Admin Tools Menu
Tips for administrator
Admin Tools Menu
Tips for administrator
If you have to comply with RGPD, here are some tips to help you…
Most of the personal information in iTop is stored in the Person object. In the standard iTop datamodel, these data consist of:
|Field code||Label||Description of the field|
|Email address of the person|
|employee_number||Employee number||Employee number or any identifier used within the company|
|first_name||First Name||First name of the person|
|function||Function||Function / job title of the person|
|location_id||Location||Location of the person (link to a Location object)|
|manager_id||Manager||Manager of the person (link to a Person object)|
|mobile_phone||Mobile Phone||Mobile phone number|
|phone||Phone||Fixed phone number|
|picture||Picture||Picture of the person|
Due to the relational nature of iTop, the information stored in the Person object is not supposed to be duplicated elsewhere. The few exceptions to this principle are listed below:
All modification to the Person object are recorded in the history of this Person object, thus storing some personal information. You can list all the changes made to a given Person object using the following OQL query:
SELECT CMDBChangeOp WHERE objclass='Person' AND objkey=:person_id
Where :person_id is the identifier of the Person object. All the modifications performed by the user account associated with the contact also keep track of the name (i.e. friendlyname) of the contact who made the changes.
SELECT CMDBChange WHERE userinfo=:person_name
Where :person_name is the complete name (i.e. friendlyname) of the Person, for example “Claude Monet”.
Case Log field in iTop stores information about the person who created each entry in the case log (in the current version of iTop it is not possible to modify a case log entry). The information recorded in the case log (for each entry) contains:
For example, if the user associated with the Person “Claude Monet” (id=3) created two case log entries, the content of the case log will be stored in the database as follows:
========== 2018-05-09 11:38:45 : Claude Monet (3) ============ <p>This is the second entry of the case log</p> ========== 2018-05-09 11:38:27 : Claude Monet (3) ============ <p>This is the first entry of the case log</p>
Whenever a notification is sent by iTop as an eMail, the information is recorded in the
EventNotificationEmail object. This object records the email sent to the mail server. This object contains the email addresses of the person it was addressed (in TO, CC or BCC) and the content of the message sent.
The EmailNotification object also stores the date at which it was emitted.
One of the important topics when dealing with personal data is to document the flow of personal data within your organization. This document (and iTop itself) cannot document this flow for you since each use case is specific and depends on the processes and integrations put in place when operating iTop. However, iTop provides several features which can help you document and control this flow of information.
You can audit the operations performed via the REST/JSON services by setting the configuration parameter ‘log_rest_service’ to true in the iTop configuration file. Once this parameter is set, every REST/JSON operation will create an EventRestService object in the iTop database. This object records:
Using all the information you can determine the flow of personal information via REST/JSON webservices (if any).
You can easily list all Synchro Data Sources which import of update Persons by search searching for Synchronization Data Sources which “Target Class” is “Person”. This search can be performed through the “Admin tools / Synchronization Data Sources” or by running the following OQL query:
SELECT SynchroDataSource WHERE scope_class='Person'
Each data source keeps track of a complete log of its operations, including the date/time it was run and the summary of the operations executed for each run (creations/updates/deletions).
Note that if a “User” is specified for a Synchronization Data Source, then only the specified user account can execute this synchronization.
To completely cleanup the data related to a person, one has to:
But there are limitations to those actions:
Due to the limitations mentioned above the “pseudonymization” approach seem more realistic to implement than a complete wipe of the personal data.
This can be achieved using the “Run Query” menu and an OQL like:
SELECT UserRequest WHERE (public_log LIKE :name OR private_log LIKE :name)
specifiying the value of the :name parameters as %contact_friendlyname%.
For example to export all the User requests with an entry by Claude Monet in a case log, the OQL query would be:
SELECT UserRequest WHERE (public_log LIKE '%Claude Monet%' OR private_log LIKE '%Claude Monet%')
Notification emails can be listed and exported using the OQL query:
SELECT EventNotificationEmail WHERE TO = 'email_address' OR cc LIKE '%email_address%' OR bcc LIKE '%email_address%'