Write auxiliary data when updating/creating objects #48

New issue

Open

opened 2022-10-29 22:38:42 +02:00 by nik · 8 comments

nik commented

2022-10-29 22:38:42 +02:00

Owner

Some LDAP implementations rely on special state objects to track IDs. An example is Puavo's ID tracking object:

cn=IdPool,o=puavo
objectClass: top
objectClass: puavoIdPool
cn: IdPool
puavoNextRid: 3
puavoNextDatabaseId: 1
puavoNextKadminPort: 10004
puavoNextGidNumber: 10007
puavoNextUidNumber: 10005
puavoNextId: 17

We need a method to update values in such ID objects when modifying the tree from AlekSIS.

Some LDAP implementations rely on special state objects to track IDs. An example is Puavo's ID tracking object: ```ldif cn=IdPool,o=puavo objectClass: top objectClass: puavoIdPool cn: IdPool puavoNextRid: 3 puavoNextDatabaseId: 1 puavoNextKadminPort: 10004 puavoNextGidNumber: 10007 puavoNextUidNumber: 10005 puavoNextId: 17 ``` We need a method to update values in such ID objects when modifying the tree from AlekSIS.

nik commented

2022-10-29 22:38:42 +02:00

Author

Owner

assigned to @magicfelix

magicfelix commented

2023-03-20 16:24:27 +01:00

Member

assigned to @nik and unassigned @magicfelix

magicfelix commented

2023-03-20 22:00:45 +01:00

Member

Also includes the general implementation of AlekSIS -> LDAP sync (using signals?), which is currently not implemented and only possile by using write_model_to_ldap manually.

Also includes the general implementation of AlekSIS -> LDAP sync (using signals?), which is currently not implemented and only possile by using `write_model_to_ldap` manually.

nik commented

2023-03-21 23:26:36 +01:00

Author

Owner

So, here are two ideas how to implement this, both somewhat related. @magicfelix Do you have an opinion? DOes any of these solutions sound good? If so, can you implement it with my guidance?

Sync the ID pool object like any other, then refer to it

Implement a Django model PuavoIdPool, and configure an LDAP mapping set for it just like with any other model.
Add configuration to LDAP attribute mappings to refer to fields in that model
Add logic to LDAP sync ensuring the pool model is synced before and after the real object

This implementation needs a model specific to the target, e.g. Puavo.

Use raw LDAP for the references

For each LDAP attribute mapping, add a configuration for a "Pool LDAP DN" and "Pool LDAP attribute".
Also add an option specifying what to do with the data retrieved from the pool:
- Use only (use the value, but don't change it)
- Use and increment (Use the value, then increment it in LDAP afterwards)
- Increment and use (Increment the value first, then use the incremented value)
Implement a method to refer to the pool value in the "write template"
Use raw LDAP to do the necessary reads/write during sync
In the frontend: These additional fields should not clutter the UI. Maybe use an Ausklappable of some sort.

So, here are two ideas how to implement this, both somewhat related. @magicfelix Do you have an opinion? DOes any of these solutions sound good? If so, can you implement it with my guidance? ## Sync the ID pool object like any other, then refer to it 1. Implement a Django model `PuavoIdPool`, and configure an LDAP mapping set for it just like with any other model. 2. Add configuration to LDAP attribute mappings to refer to fields in that model 3. Add logic to LDAP sync ensuring the pool model is synced before and after the real object This implementation needs a model specific to the target, e.g. Puavo. ## Use raw LDAP for the references 1. For each LDAP attribute mapping, add a configuration for a "Pool LDAP DN" and "Pool LDAP attribute". 2. Also add an option specifying what to do with the data retrieved from the pool: * Use only (use the value, but don't change it) * Use and increment (Use the value, then increment it in LDAP afterwards) * Increment and use (Increment the value first, then use the incremented value) 3. Implement a method to refer to the pool value in the "write template" 4. Use raw LDAP to do the necessary reads/write during sync 5. In the frontend: These additional fields should not clutter the UI. Maybe use an Ausklappable of some sort.

nik commented

2023-03-21 23:34:05 +01:00

Author

Owner

Please break that out into a separate issue (or is there a good reason that these issues are related?)