Streamlining behavior when deleting user accounts

1 Requirements

1.1 Current state in ILIAS v5.0

First an analysis of the current state what happens to existing objects and content fragments when a user will be deleted:

Summary

 

 

1.3 Proposal

Based on these analysis of the current state I will here develop a proposal for streamlining the behavior of ILIAS when a user will be deleted.

Own objects in the personal workspace

should be deleted as in the current state

Own objects in the repository

Different behavior could be desired dependent on the user and the objects in question:

• The object persists and looses its ownership. Therefore it becomes ownerless.

• The object persists and changes the ownership to the owner of the next higher object in the repository tree (the surrounding folder, group, course or category).  [Should be the default behavior]
  When the object is on the highest level of the repository, then root becomes the owner.

• The object persists and changes the ownership to a user-defined or selected owner.

• If the object is a content object:

  • The object will be deleted. A warning should be thrown prior to the deletion.

  If the object is a container object (category, course, group, folder):

  • If the object contains objects of other owners, the object should persist and an other rule has to be chosen concerning the ownership (see above).

  • If the object only contains objects of the same owner, the object should be deleted including all embedded objects. A warning should be thrown prior to the deletion.

Content fragments of foreign objects

The behavior of all objects should be consistent but different behavior could be desired:

• The content fragment persists and the user is displayed as "The user has been deleted.".  [Should be the default behavior]

• The content fragment persists and the name (academic title, firstname, lastname) of the user will be preserved.[2]

• The content fragment will be deleted. A warning should be thrown prior to the deletion.

Content fragments where the user is displayed as "unknown" or where the user field is empty after the deletion of a user are not desirable.

 

1.4 Mock-ups

Administration » User Management:

(in preparation)

Administration » General Settings: Cron Jobs:

Delete inactivated user accounts

and when selecting the last option of "User objects in the repository":

Delete inactive user accounts

Mock-up analogous to the mock-up of "Delete inactivated user accounts" above.

1.5 Enhancements

Maybe it should be possible to define the default behavior based on global roles.

Considering authors of learning content. It won't make sense if their objects (e.g. learning modules, question pools and glossaries) would be deleted when they leave an institution. Contrary to tests passes which could be deleted because they are mostly for test purposes.

Considering students, this could be the other way round. Here test passes could be examination fragments and the name of the student user should be preserved in the test results even if the student already left the university.

Furthermore, it could be desired to define the default behavior in more detail based on object types.

2 Additional Information

• Idea / concept: Mirco Hilbert, JLU Gießen, Mirco.Hilbert@hrz.uni-giessen.de
• Interest in funding: (please indicate if you are interested/able to fund this feature)
• Maintainer: (will be set by Jour Fixe / maintainer)
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

3 Discussion

4 Implementation

{please give a descripiton of the final implementation and add screenshots if possible}

Test Cases

Test cases completed at {date} by {user}

• {Test case numberlinked to Testrail} : {test case title}

Approval

Tested successfully and approved at {date} by {user}.