Hello
I am working on a overlay (the same as last time with the internal search question) that produce dynamic values depending on multiple attributes.
The model was slapo-dynlist. I added an on_response method and I was able to produce everything needed when handling a search request. That works like a charm.
But now I would like to use the generated values in a filter when searching. In some cases, I can modify the filter on the fly in bi_op_search so that it works, but that is not always possible.
I thought of two alterantives:
1) In supann_op_add and supann_op_modify, perform an internal modify operation, so that the generated values are actualy added to the entry. But There is a problem: I exit that two methods without knowing if the add or modify operation succeded or not. The dynamic values should not be added if the add/modify operation failed.
2) I could steal some ideas from slapo-dds to update entries in the whole directory on a regular basis. That seems to do a lot of useless activity, and changes will always lag a bit. For now it seems to be the best option.
Is there another was of doing it?
Emmanuel Dreyfus wrote:
Hello
I am working on a overlay (the same as last time with the internal search question) that produce dynamic values depending on multiple attributes.
The model was slapo-dynlist. I added an on_response method and I was able to produce everything needed when handling a search request. That works like a charm.
But now I would like to use the generated values in a filter when searching. In some cases, I can modify the filter on the fly in bi_op_search so that it works, but that is not always possible.
I thought of two alterantives:
- In supann_op_add and supann_op_modify, perform an internal modify
operation, so that the generated values are actualy added to the entry. But There is a problem: I exit that two methods without knowing if the add or modify operation succeded or not. The dynamic values should not be added if the add/modify operation failed.
- I could steal some ideas from slapo-dds to update entries in
the whole directory on a regular basis. That seems to do a lot of useless activity, and changes will always lag a bit. For now it seems to be the best option.
Is there another was of doing it?
It's still unclear what you're trying to do in this overlay, so I can't guess at what alternatives might exist.
On Mon, Dec 22, 2025 at 04:58:58PM +0000, Howard Chu wrote:
It's still unclear what you're trying to do in this overlay, so I can't guess at what alternatives might exist.
I did not want to annoy everyone with the details, but here we go.
There is a directory layout specification for french higher education institutes called supann [1]. It defines various attributes, incuding "composite attributes" that fold a lot of data. Here is an example for the attribute that describes student enrollment in a master's degree.
supannEtuInscription: [etab={UAI}0751717J][anneeinsc=2019] [regimeinsc={SISE}10][sectdisc={SISE}38][typedip={SISE}XB] [cursusann={SUPANN}M2][diplome={SISE}2500005] [population={SUPANN}AGEI][datefin=20201130220000Z]
Composite attributes are made of [key=val] components. The specification says that for each component, there must be a plain attribute (named "elementary attribute" in the spec) that holds the value. So if we have the supannEtuInscription above, we must also have: supannEtablissement: {UAI}0751717J supannEtuAnneeInscription: 2019 supannEtuRegimeInscription: {SISE}10 supannEtuSecteurDisciplinaire: {SISE}38 supannEtuTypeDiplome: {SISE}XB supannEtuCursusAnnee: {SUPANN}M2 supannEtuDiplome: {SISE}2500005 supannCodePopulation: {SUPANN}AGEI supannEtuDateFin: 20201130220000Z
My current work is slapo-supann. It automatically produces the elementary attributes from the composite attribute. That part works by adding dynamic attributes in search responses. I also added syntax checks so that the data inserted in composite attribute is sane. That works too.
There are other stuff generated. I use the datefin components to produce an attribute telling when the user account it active (A) or inactive (I) supannRessourceEtatDate: {COMPTE}A:SupannActif::20201130 supannRessourceEtatDate: {COMPTE}I:SupannExpire:20201130:
And, using current date, I generate an attribute telling if the account is active or not: supannRessourceEtat: {COMPTE}I:SupannExpire
Tha ability to filter on this generated attribute would be very nice. A service filter could require: (&(objectClass=supannPerson)(supannRessourceEtat={COMPTE}A:*))
And the question is: how to do it? As I explained, the only alternative I see is (1) to insert the data in the directory instead of adding it as dynamic during searches, or (2) to do a periodic refresh of that attribute by borrowing code from slapo-dds. I wonder if there are other options.
Another question is about inclusion of that stuff in contrib/slapd-modules. Do you think that it makes sense?
[1] https://services.renater.fr/documentation/supann/index
Emmanuel Dreyfus wrote:
On Mon, Dec 22, 2025 at 04:58:58PM +0000, Howard Chu wrote:
It's still unclear what you're trying to do in this overlay, so I can't guess at what alternatives might exist.
I did not want to annoy everyone with the details, but here we go.
There is a directory layout specification for french higher education institutes called supann [1]. It defines various attributes, incuding "composite attributes" that fold a lot of data. Here is an example for the attribute that describes student enrollment in a master's degree.
supannEtuInscription: [etab={UAI}0751717J][anneeinsc=2019] [regimeinsc={SISE}10][sectdisc={SISE}38][typedip={SISE}XB] [cursusann={SUPANN}M2][diplome={SISE}2500005] [population={SUPANN}AGEI][datefin=20201130220000Z]
Composite attributes are made of [key=val] components. The specification says that for each component, there must be a plain attribute (named "elementary attribute" in the spec) that holds the value. So if we have the supannEtuInscription above, we must also have: supannEtablissement: {UAI}0751717J supannEtuAnneeInscription: 2019 supannEtuRegimeInscription: {SISE}10 supannEtuSecteurDisciplinaire: {SISE}38 supannEtuTypeDiplome: {SISE}XB supannEtuCursusAnnee: {SUPANN}M2 supannEtuDiplome: {SISE}2500005 supannCodePopulation: {SUPANN}AGEI supannEtuDateFin: 20201130220000Z
My current work is slapo-supann. It automatically produces the elementary attributes from the composite attribute. That part works by adding dynamic attributes in search responses. I also added syntax checks so that the data inserted in composite attribute is sane. That works too.
Sounds like you're doing this backwards, I would've stored all the elementary attributes and dynamically created the composite attribute from them.
Do entries get created with both the composite and elementary attributes present? Are modifications done to the composite, or to the elementary attributes?
There are other stuff generated. I use the datefin components to produce an attribute telling when the user account it active (A) or inactive (I) supannRessourceEtatDate: {COMPTE}A:SupannActif::20201130 supannRessourceEtatDate: {COMPTE}I:SupannExpire:20201130:
And, using current date, I generate an attribute telling if the account is active or not: supannRessourceEtat: {COMPTE}I:SupannExpire
Tha ability to filter on this generated attribute would be very nice. A service filter could require: (&(objectClass=supannPerson)(supannRessourceEtat={COMPTE}A:*))
And the question is: how to do it? As I explained, the only alternative I see is (1) to insert the data in the directory instead of adding it as dynamic during searches, or (2) to do a periodic refresh of that attribute by borrowing code from slapo-dds. I wonder if there are other options.
Another question is about inclusion of that stuff in contrib/slapd-modules. Do you think that it makes sense?
On Mon, Dec 22, 2025 at 09:16:12PM +0000, Howard Chu wrote:
Sounds like you're doing this backwards, I would've stored all the elementary attributes and dynamically created the composite attribute from them.
The composite attribute holds the relation between its components. A student could be enrolled in two degrees with differend ending dates. In such a case, it is not possible to construct the two composite attributes from the elementary attributes. You do not know what date is for what degree.
Do entries get created with both the composite and elementary attributes present? Are modifications done to the composite, or to the elementary attributes?
No, all elementay attributes are derivated from composite attributes. Only the composite attribute are edited.
slapo-supann enforces the rule, returning LDAP_UNWILLING_TO_PERFORM on elementary attribute modifications.
On Mon, Dec 22, 2025 at 05:40:45PM +0000, Emmanuel Dreyfus wrote:
On Mon, Dec 22, 2025 at 04:58:58PM +0000, Howard Chu wrote:
It's still unclear what you're trying to do in this overlay, so I can't guess at what alternatives might exist.
I did not want to annoy everyone with the details, but here we go.
There is a directory layout specification for french higher education institutes called supann [1]. It defines various attributes, incuding "composite attributes" that fold a lot of data. Here is an example for the attribute that describes student enrollment in a master's degree.
supannEtuInscription: [etab={UAI}0751717J][anneeinsc=2019] [regimeinsc={SISE}10][sectdisc={SISE}38][typedip={SISE}XB] [cursusann={SUPANN}M2][diplome={SISE}2500005] [population={SUPANN}AGEI][datefin=20201130220000Z]
Composite attributes are made of [key=val] components. The specification says that for each component, there must be a plain attribute (named "elementary attribute" in the spec) that holds the value. So if we have the supannEtuInscription above, we must also have: supannEtablissement: {UAI}0751717J supannEtuAnneeInscription: 2019 supannEtuRegimeInscription: {SISE}10 supannEtuSecteurDisciplinaire: {SISE}38 supannEtuTypeDiplome: {SISE}XB supannEtuCursusAnnee: {SUPANN}M2 supannEtuDiplome: {SISE}2500005 supannCodePopulation: {SUPANN}AGEI supannEtuDateFin: 20201130220000Z
Hi Emmanuel, this looks suspicious to me, if supannEtuInscription is multi-valued, how do you handle the other attributes with respect to filters (e.g. supannEtuDateFin comparisons are no longer sane), etc.?
Storing those degrees(?) as separate children entries sounds a little saner, depending on the use case.
Regards,
On Tue, Jan 06, 2026 at 11:54:50AM +0100, Ond?ej Kuzník wrote:
this looks suspicious to me, if supannEtuInscription is multi-valued, how do you handle the other attributes with respect to filters (e.g. supannEtuDateFin comparisons are no longer sane), etc.?
supannEtuDateFin is indeed special, the specification requires that only the highest value is present in the elementary attribute.
Storing those degrees(?) as separate children entries sounds a little saner, depending on the use case.
Well, I am not participating to the standard's working group, I just take the specification as it was written, and I try to write a tool to make my life easier with it.
On Mon, Dec 22, 2025 at 03:05:35PM +0000, Emmanuel Dreyfus wrote:
But now I would like to use the generated values in a filter when searching. In some cases, I can modify the filter on the fly in bi_op_search so that it works, but that is not always possible.
I thought of two alterantives:
- In supann_op_add and supann_op_modify, perform an internal modify
operation, so that the generated values are actualy added to the entry. But There is a problem: I exit that two methods without knowing if the add or modify operation succeded or not. The dynamic values should not be added if the add/modify operation failed.
Replying to myself: When bi_op_modify or bi_op_add detect that the change would require a subsequent attribute addition to the entry, the modification is queued in the overlay private structure.
In on_response, if ((rs->sr_tag == LDAP_RES_MODIFY || rs->sr_tag == LDAP_RES_ADD) && rs->sr_err == LDAP_SUCCESS) then the modification is performed.
-
Emmanuel Dreyfus -
Howard Chu -
Ondřej Kuzník