(switching to) LDAP Backend with uid/gid collides with modlog

[lab-at-nohl]

Initially set User/Groups Backend to LDAP works, though.

Although the switch deletes the existing installation (all Users, Groups, Roles are removed and populated with new ones from LDAP, existing user data belongs to the old users...), it might be of use for installation. If not, it should be disabled (no changes after a successful installation on Backend: SQL).

I could identify two problems that breaks the migration:

• In Tinebase_User_SQL and Tinebase_Group_SQL changes fail. Users/Groups aren't deleted but marked to is_deleted, but the accountId for the setupuser is unknown to Tinebase_Core::getUser()->getId(); Core is not initialized.
• Despite Tinebase_ACL_Roles delete routine works, the new Roles cannot be created because they have the same name as the Roles marked as is_deleted (unique on DB level).

Nevertheless, you can manually make your installation play with LDAP.

[lab-at-nohl]

I just realized that changing backend in setup.php is just one case. The problem is more general: If Backend uses uid/gid as identification, SQL Backend reuses the same id. This also applies to adding a user after another one is deleted; LDAP uid/gid is reused and mirrored back to SQL Backend (which collides with the already deleted user). Same for groups.

However, LDAP with entryUUID works.

[pschuele]

yup, the switch from an existing (sql user backend) installation to ldap is problematic right now. i think, we should disable that for the moment.

If Backend uses uid/gid as identification, SQL Backend reuses the same id. This also applies to adding a user after another one is deleted; LDAP uid/gid is reused and mirrored back to SQL Backend (which collides with the already deleted user). Same for groups.

users/groups should be hard-deleted in this case (maybe always with ldap backend?)

[pschuele]

see this change for switching back to configurable hard/soft delete: 1220f1c

[lab-at-nohl]

Well, the decision for hard/soft delete is very clear imho:

1. In setup.php when switching Backends, always hard with a big warning. Of course it would be preferable to "integrate" into an existing installation. However, I am not aware of a neat method to change not only primary keys of accounts/groups but also all related foreign keys in all existing tables. Especially if you cannot use transactions because you have to disable constraints (when I did it with my production system, almost 10 years ago ;-), I wrote a script for that - lot of work).
2. Also hard delete is always necessary if Ldap with uid/gid identifier is configured. Because Ldap backend will reuse freed uid/gid but SQL sees them as duplicates. Thus, setup.php should have a warning if uid/gid is chosen.

Finally, it seems not reasonable to me that someone wants to keep the old data after switching User Backend. It is not available anymore. Maybe it would be nice to offer a backup or so. But changing User Backend should occur only in empty installations!