Add an archival plugin to fusiondirectory
Add an archival plugin to fusiondirectory
Actual behavior
There is no account archival plugin.
Expected behavior
Be able to store a striped down object only for archival purposes:
- it should contain a minimal number of attributes
- it should be compliant with the RGPD (aka minimal information needed for the service needed)
- it should not be used as a snapshot we can restore
- it should be configurable on which attributes should be saved except for the attributes FusionDirectory need to show the entries correctly, a tab in the configuration backend for archival needs to be created
- it should store those account in a ou=archive branch
Step by step description of new behaviour
- In the configuration, activate archive for type user, selecting which field should be kept
- In the ACLs, give rights user/archive/cdr to the admin
- Use the Archive action on a user / several users
- An archive of the user is created in
ou=archive,<baseoftheuser>with only the attributes we selected in the configuration backend - The user is deleted from its original branch upon successful creation
- The archive have a reference to original dn
- The archive have a timestamp of the time it was created
- The archive have a specific objectClass for filtering
LDAP example of an archive:
dn: cn=asmith,ou=archive,o=organization1,dc=example,dc=com
cn: asmith
fdArchivedDn: uid=asmith,ou=people,o=organization1,dc=example,dc=com
fdArchivedDate: 2021070500Z
fdArchivedType: USER
fdArchivedUniqueField: uid:asmith
fdArchivedField: homeDirectory:/home/asmith
fdArchivedField: uidNumber:1337
objectClass: fdArchivedObjectACL rights on special fake class type/archive (inspired by type/template):
- type/archive/c -> allow to archive(and delete) objects
- type/archive/d -> allow to delete archive objects
- type/archive/r -> allow to read archive data
Benefits
Have a structured way of storing the archival of the accounts of people no longer there.
Make sure values for unique attributes like uid, uidNumber or mail are not re-used by new users.
Applicable Issues
Archiving account in the education / research fields
Tasks
0No tasks are currently assigned. Use tasks to break down this issue into smaller parts.
Linked items
- user-manual #135FusionDirectory 1.4
Activity
added PJ1802-0188 label
changed milestone to %FusionDirectory 1.4
We need to decide between:
Use a generic objectClass and field like for templates
Example (archived fields are uid, homeDirectory and uidNumber)
dn: cn=asmith,ou=archive,dc=example,dc=com cn: asmith fdArchivedDn: uid=asmith,ou=people,dc=example,dc=com fdArchivedDate: 2021070500Z fdArchivedType: USER fdArchivedUniqueField: uid:asmith fdArchivedField: homeDirectory:/home/asmith fdArchivedField: uidNumber:1337 objectClass: fdArchivedObjectPros
- No risk of archived users being misread as real users by a badly configured application
- No need for dummy values (see below)
- We can use 2 attributes to differentiate between archive for history and archive for reservation (unicity, marked with fdArchivedUniqueField in our example).
Cons
- Unicity check filters will need to explicitly include archived fields, like
(|(cn=joe)(fdArchivedUniqueField=cn:joe)) - Need to serialize binary fields
Keep the original objectClasses
Example (archived fields are uid, homeDirectory and uidNumber)
dn: uid=asmith,ou=archive,dc=example,dc=com uid: asmith fdArchivedDn: uid=asmith,ou=people,dc=example,dc=com fdArchivedDate: 2021070500Z fdArchivedType: USER fdArchivedFields: uid fdArchivedFields: uidNumber fdArchivedFields: homeDirectory sn: dummy cn: dummy homeDirectory: /home/asmith uidNumber: 1337 gidNumber: 0 objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: fdArchivedObjectPros
- Easier to read by an external application (like if an email server can check which email addresses are already taken through an LDAP request).
- Easier to archive non-textual field, like jpegPhoto (solution 1 will need to serialize it)
Cons
- We will need to keep all mandatory fields for those objectClasses, or use a dummy value (but each field syntax may need a different dummy value - in the example I added fdArchivedFields list to help now if a field has a dummy value or a real one).
-
Regarding performance:
When unicity of a field is checked (currently each time an object containing a unique field is saved), the search will change a bit.
Most likely we will end up doing a second LDAP search for archived fields in both cases. The field fdArchivedUniqueField should be added to the index for solution 1 to speed these searches. We could pre-detect if archive is activated for this objectType first to only run this search if it is.
The only case where we may do only one search for both normal and archive unicity is when the unicity is set to be across the whole tree (value 'whole' in $unique). For solution 2 we may even use the same filter. For solution 1 the filter will change to include a search on fdArchivedUniqueField. But doing only one search in this case would make the PHP code more complex since it means 'whole' unicity and 'one' unicity would have different workflows.
Making 2 searches also allow to put this in a plugin as originally intended (second search only triggers if plugin is installed and archive is active for the object type).
-
An other important question is the ACLs related to this.
I can imagine the following situations:
- Some users are allowed to archive users, but not to delete them (without archive)
- Some users are allowed to consult archived users, but read-only
Does it make sense to split archive and delete actions? It would be simpler if when archive is activated for a type, any deletion of an object will archive it. It is a limitation, but maybe acceptable? Which usecases would go against this?
mentioned in commit 367b3527
mentioned in commit f716edfd
mentioned in commit 2611a0d9
mentioned in commit ffecc0b9
mentioned in commit f2039c72