[OAE] Delete User

[claire lozano]

Hi everyone,

        

As you probably know, the European Commission proposed a reform of the data protection regulation in the EU that we have to comply to starting May 2018.

    

One of these rules is the "Right to be forgotten"... which is not implemented in OAE as it.

As of today, “deleting a user” means "adding a deleted flag to the entry" and that's pretty much it. The user can no longer log in but we don’t delete any of their data... Hence why we decided to modify the "delete user" function in order to make sure that all their "private" data would be actually removed.

      

I've already started the development and for now, the function deletes...    

... the user from the “Principals” table

... all their rights on resources  (discussions, folders, contents, groups).  Note: if the user is the only one to have access to a resource, then the resource itself is removed from the database...

... the documents are deleted from the file system (when applicable). Note: I'm not sure this is working properly TBH... even when I simply try to delete a resource from the file system using the existing feature in OAE, I still can see the file on the disk... (well, that's not quite right: I've tried several times to delete a content in OAE, and only once did it actually disappeared from my file sytem...). Am I missing something here?

... all references to the user in the social network (data removed from the “FollowingUsersFollowing” and “FollowingUsersFollowers” tables).

     

It's obviously a work in progress but feel free to check out the code on my github: https://github.com/ClaireLozano/Hilary/tree/deleteUser

    

Please let me know if you have any questions, problems or concerns about this "new" feature. 

    

Best,

    

Claire 

[Salla Karppinen]

Hi Claire,

yes, this sounds like a feature that we will definitely need, not only to comply with European law but also to ensure that if a university requests we remove some data we are able to do so. My only comment is with regard to documents: when a document has been shared with others but is owned by the user being deleted, do we want to remove it even though that means taking it away from the other users as well?

Regarding deleting documents, we keep the actual document and previews of it in the filesystem (in the base folder specified in config.js, under subfolders keyed on the tenantAlias and type of content, as you know). It could be that you're only deleting one or the other? Which method are you using to delete from filesystem? The `deleteContent` in `ContentAPI` actually just removes the item from the database and the library, unlike it's name suggests. However, the `remove` method in the content backends should actually remove the file, so if you're using that one I'm not sure what's causing the problem... Using the backends directly needs to be done with care though as we want to make sure the functionality is the same whether the instance is using local or remote storage.

I don't know if that was of any help, but please let me know how you get on!

Thanks,

Salla

[claire lozano]

Hi everyone, 

a few days ago, we had a meeting with a CIL (while it's not entirely true, let's just say that a CIL is kinda like a Chief Data Officer...) to talk about this "delete a user (and their data)" feature and to discuss how to handle this in the OAE (ie. a collaborative) context. He suggested that we make some changes on our implementation to be more compliant on the current (and upcoming) regulations regarding the right to be forgotten, data privacy & ownership on collaborative resources.

In the end, here is what we came up with:

> For each tenant, we create an "Archive account", only accessible by the tenant administrator(s). This account is used as a "temporary repository" for resources previously owned by now-deleted users. Having this account make it possible for an admin to give access to one of these "resources" if someone wants to access it again. (see below)

> When a user (userToDelete) is being "deleted", we've identified 5 different cases about his/her resources:
        - case 1: userToDelete is the sole manager of the resource and no other users can access/edit it => the resource is definitively deleted after a X-days delay (X being defined by the admin)
        - case 2: userToDelete is the manager of the resource along with another user (otherManager) => userToDelete loses their right on the resource and otherManager is notified of this change
        - case 3: userToDelete is the sole manager of the resource but at least one user can view it (otherViewer) => notify otherViewer, transfer the resources to the "archive account" (this account is now the sole manager/owner of the document)
        - case 4: userToDelete has "can view" rights on a resource who is managed by an otherManager => we remove the userToDelete's (access) right on the resource and notify otherManager
        - case 5: userToDelete is the sole manager of the resource but another user has "can edit" right on the resource (anotherEditor) =>  anotherEditor becomes the manager of the resource and userToDelete's right on the resource is revoked
> All the personal information (name, e-mail,...) of the user is deleted right away

> After X days/months, the "archived" contents are definitely deleted.

Some other things we thought of regarding users deletion:

> Notifications:
    - if a user hasn't logged in a year, then we send him/her an e-mail to invite them to -at least- log in once in order not to loose their account.
    - if the user hasn't logged 3 months after the "warning", a notification will automatically be sent to the tenant admins to let them know of this inactive account. While the tenant administrators can choose to ignore this notification, we strongly suggest that they delete the account.
> Reporting:
    - Make it possible for an tenant administrator to get a report listing all the users: <OAE_ID, first & last name, e-mail, last login date> (Note: we could add some basic filters and/or sort methods like: list all users not having logged in in the X last months, sort by last login date, etc.)

> Massive account deletion:
    - in the user management interface, make it possible for an admin to select the different users they want to delete and have those deleted just by clicking a "Delete selected accounts" button.
    - and/or make it possible for an admin to delete specific users by providing a list of their OAE_IDs instead of having to manually check each account they want to delete in the UI.

Feel free to comments or ask questions for further explanation if necessary.

Best,

Claire L.

--
You received this message because you are subscribed to the Google Groups "Open Academic Environment (OAE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oae+uns...@apereo.org.
To post to this group, send email to o...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/oae/.