hi antoine,
supann recommends indeed to set everyone flat below ou=people, but I should
have said that my destination directory must (before all) be "fusionDirectory
[1] compliant", so that I can benefit from fusionDirectory roles and ACL to
delegate subtrees to different group of managers.
so I confirm that my src ldap is flat below ou=people and I want a destination
directory with subtrees below ou=people
then would it be just a matter of semantic by changing the name of variables
(dst_ou to src_ou) like this :
<mainIdentifier>
<![CDATA[js:
var src_ou="";
try {
src_ou =
srcBean.getDatasetFirstValueById("employeeType");
}catch(err){
src_ou = "default";
}
"UID=" + srcBean.getDatasetFirstValueById("UID") + ", ou=" +
src_ou + "OU=people, dc=site"
]]>
</mainIdentifier>
what's the use case of catch(err){ src_ou = "default";} , that is if
employeeType is not defined for an entry then it will be put in
uid=idxxx,ou=default,ou=people,dc=site ?
thanks .
[1]
https://www.fusiondirectory.org/
----- Mail original -----
De: "Gallavardin Antoine" <[email protected]>
À: "General discussions and help for Ldap Synchronization Connector, (LSC) -
Start here!" <[email protected]>, "Jehan PROCACCIA"
<[email protected]>
Envoyé: Lundi 6 Mai 2019 15:57:50
Objet: Re: [lsc-users] sub ou and test of existence of destination identity
hi Jehan
If I understand , your _destination_ ldap should be supann compliant .
In this case, you mustn't have sub OU inside people OU [1]
If it's your src LDAP which is supann compliant, you can insert a king
of javascript
like
<mainIdentifier>
<![CDATA[js:
var dest_ou="";
try {
dest_ou =
srcBean.getDatasetFirstValueById("employeeType");
}catch(err){
dest_ou = "default";
}
"UID=" + srcBean.getDatasetFirstValueById("UID") + ", ou=" +
dest_ou + "OU=people, dc=site"
]]>
</mainIdentifier>
Antoine
I'dont see if employeetype is multivaluated ..
[1]
https://services.renater.fr/documentation/supann/supann2018/recommandations2018/modele/dit#ou_people
Le 06/05/2019 à 15:35, Jehan PROCACCIA a écrit :
> Hello
>
> I would like to jump on this because I need to do something similar I guess ?
>
> I use LSC to sync from openldap to openldap , but the destination instance
> would be supann compliant, so lots of dataset to create or modify attributes
> (seems to work fine for now ...)
> Moreover I want to split people from src to dst to different branches. for
> example if in src employeeType=staff dst would be
> ou=staff,ou=people,dc=domain,dc=fr and if src employeeType=student dst would
> be ou=student,ou=people,dc=domain,dc=fr (in src everyone is "flat" at
> ou=people )
> so I am asking how to set mainIdentifier in order to achieve that purpose ?
> without changes in sub-branches at dst , it worked fine with
> <mainIdentifier>srcBean.getMainIdentifier()</mainIdentifier>
> but in order to split in differents branches, how should I set this ?
>
> thanks .
>
> ----- Mail original -----
> De: "Clément OUDOT" <[email protected]>
> À: [email protected]
> Envoyé: Lundi 6 Mai 2019 15:12:51
> Objet: Re: [lsc-users] sub ou and test of existence of destination identity
>
> Le 06/05/2019 à 11:42, Gallavardin Antoine a écrit :
>
>
>
>
> Hello
>
>
>
>
>
>
> Hello Antoine,
>
>
>
> BQ_BEGIN
> The only workaround I found is :
> <![CDATA[js:
> var dest_dn="";
> try {
> dest_dn = dstBean.getMainIdentifier();
> }catch(err){
> dest_dn = "CN=" +
> srcBean.getDatasetFirstValueById("cn") + ",OU=people, dc=site"
> }
> dest_dn;
> ]]>
>
>
>
>
>
> Is it a correct way ? maybe a better solution exist ( I see in archive that
> lsc 2.2 will be more flexible in this case )
> BQ_END
>
>
>
>
>
> In this case, I often split the task between a creation taks and a
> modification task. The creation task will add entries in ou=people. The
> modification task will use the empty mainIdentifier (or like you have done
> the dstBean.getMainIdentifier()).
> But your solution seems correct too.
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
https://lists.lsc-project.org/cgi-bin/mailman/listinfo/lsc-users
