Hello Peter,
Here is the high level list of what need to done to "hard delete" user from
the system:
1. delete user
2. delete all user contacts (also users, so we might have recursion here)
3. delete user from all groups
4. delete user from room moderators
5. delete all appointments with owner == user
6. delete all calendars with owner == user
7. delete all meeting members in appointments where owner != user
8. delete all Private Messages where user is in to/from fields
9. delete all UserContact + Requests
10. delete all invitation sent by this user
11. delete all private rooms owned by this user
12. delete all user private files/recordings
13. delete all chat messages send/received by this user
14. clean email messages
15. clean all Polls/answers
This list scares me a lot :(((
So let's discuss the option: "Mark user deleted and clean-up sensitive
information"
What I would propose:
In Admin->User area
1. display all users (deleted should be "read-only" with restore and
purge options only)
2. add additional "Purge" button
3. In case Purge will be selected:
1. User will be marked deleted
2. AsteriskSipUser and Address will be replaced with empty objects
3. User fields "age, externaluserid, firstname, lastname, login,
pictureuri" will be replaced with "Purged_some_hash"
4. User profile picture will be deleted
5. ChatMessage: fromName will be replaced with "Purged User"
6. MailMessage: should be purged (some search by email will be
required)
ConferenceLog right now contains userId+UserIp right now, so it is 2
numbers should it be cleaned up?
SOAPLogin contains clientURL and doesn't contains userId, so it is
impossible to associate SoapLogin object with particular user
Would it be enough?
On Fri, Apr 6, 2018 at 4:21 PM, Peter Dähn <da...@vcrp.de> wrote:
> Hi Maxim,
>
> hard delete as only option would be the easiest way (for the admin). One
> doesn't need to remind "hard delete" at a given time... I think it need to
> be implemented anyway. I thought just the ones that doesn't need to take
> care about these regulation could keep things as they are now...
>
> Greetings Peter
>
>
> Am 06.04.2018 um 10:09 schrieb Maxim Solodovnik:
>
>> I'm afraid there will be no option to "final delete one record"
>> It will be: perform total clean-up and hard delete all soft deleted
>> records
>>
>> Or better to perform: hard delete as the only option?
>>
>> On Fri, Apr 6, 2018 at 2:44 PM, Peter Dähn <da...@vcrp.de> wrote:
>>
>>> Hi Maxim,
>>>
>>> "soft" and "final delete" should be enough I think...
>>>
>>> It just need to be "findable" and described for new admins that provide
>>> the
>>> service in the EU...
>>>
>>> jira in a second...
>>>
>>> Greetings Peter
>>>
>>>
>>> Am 05.04.2018 um 17:47 schrieb Maxim Solodovnik:
>>>
>>>> Hello Peter,
>>>>
>>>> This sounds like lots of new testing :(
>>>> Will try to find time and include it in 4.0.3/4.0.4
>>>>
>>>> (have very limited time right now :( )
>>>> Will appreciated any help with testing
>>>>
>>>> Would it be OK to perform "final delete" in clean-up widget? i.e.
>>>> delete will be "soft delete", then in if will push "Clean-up" all soft
>>>> deleted data will be hard deleted ...
>>>> Or it doesn't worth to have both? only hard delete will be enough?
>>>>
>>>> On Thu, Apr 5, 2018 at 5:55 PM, Peter Dähn <da...@vcrp.de> wrote:
>>>>
>>>>> Hey there,
>>>>>
>>>>> new privacy regulations will take place on the 25th May 2018 in Europe.
>>>>> You
>>>>> could find informations about it by searching for General Data
>>>>> Protection
>>>>> Regulation (EU) 2016/679.
>>>>>
>>>>> To use openmeetings after the 25th of May (in Europe) there need to be
>>>>> a
>>>>> few
>>>>> changes. We use openmeetings integrated. So I will mainly be focused on
>>>>> the
>>>>> room.
>>>>>
>>>>> I have 3 points that are really necessary:
>>>>>
>>>>> 1. User deletion: Datasets of users that will be deleted need to be
>>>>> remove
>>>>> from the database, not just marked as deleted. Probably it is enough to
>>>>> hash
>>>>> those fields.
>>>>>
>>>>> I think critical fields are in table:
>>>>>
>>>>> om_user -> age, externaluserid, firstname, lastname,
>>>>> login,
>>>>> pictureuri (and picture itself) and sip_user_id
>>>>>
>>>>> conferencelog -> email, external_user_id, firstname,
>>>>> lastname,
>>>>> user_id, userip
>>>>>
>>>>> soaplogin -> client_url (contains the ip-address)
>>>>>
>>>>> sipusers (here empty so please check) -> defaultuser,
>>>>> host,
>>>>> ipaddr, name
>>>>>
>>>>> address -> email, fax, phone
>>>>>
>>>>> chat -> from_name
>>>>>
>>>>> e-mail_queue (if not empty) -> recipients, replyto
>>>>>
>>>>> 2. There need to be a place to place a (customized) privacy policy.
>>>>>
>>>>> 3. Registration-Dialog need to have a button/step to agree the data
>>>>> processing. And to this belongs a button to disagree.
>>>>>
>>>>>
>>>>> As far as I can see this need to be done in the first place. I'm sure
>>>>> there
>>>>> are more things to do. Maybe someone can complete it.
>>>>>
>>>>>
>>>>> Greetings Peter
>>>>>
>>>>
>>>>
>>>>
>>
>>
>
--
WBR
Maxim aka solomax
