Hi all

[and especially @daniel.pan and @Jonathan)

Could it be possible to implement one more feature in DEPT SYNC as :



We have an LDAP STRUCTURE in which




As it is shown below

Id’like to filter these because as a user i see two groups

people (i’m in people)

I don’t want to show “people” group


You may also SYNC ONLY Departements that contains on LDAP object as defined in USER_OBJECT_CLASS
Then, empty departments would not be imported



OK, we’ll put this into plan. BTW, please note that the configuration options for syncing departments have been re-designed in the latest version:


Thank you @Jonathan

Please consider that the filtering option should only bypass some OU for the display

Considering the following LDAP structure




Users are located in the branch people

The DEPTs should be



And users that are in epcc/epcc-pole-numerique/people should be located in



Yes, i noticed that and it’s really nice !



Hi @gauburtin

So your proposal is not a filter, but bypassing some levels of OU. However this doesn’t seem to be a very elegant solution to your problem. What if you have a few dozens of OU names have to be bypass? And it would introduce complexity into the implementation. Since I’m not sure how many other users need this feature, I think it would be better to change the structure of your LDAP server. “people” and “roles” are not good names for an OU anyway.


Hi @Jonathan

I think we have misunderstood each other.

When they interact with LDAP, all our applications look for users (Bind or import) wihtout bypassing underlying the ou=people node below ou=eppc-pole-numerique.

Then i think that seafile could do the same only with a FILTER condition.

Pointing to ou=eppc-pole-numerique should import all users below (subtree search), while not showing the ou=people node

I think we should make a test with a filter condition and i also think it could be as usefull as the groups filter :wink:



Hi @gauburtin

Now I understand your requirements. But it’s hard to design it correctly for the general case. Think about a case: ou=eppc, ou=eppc-pole-numerique, ou=people. What if eppc-pole-numerique is the only child node under eppc? Do we have to bypass eppc-pole-numerique? So it’s hard to tell the difference programatically.


Hi @Jonathan

After a look at the LDAP LDIF, here is the basic structure for OU and users

dn: ou=people,ou=epcc-pole-numerique,o=xxx,dc=domain,dc=ext
objectClass: organizationalUnit
ou: people


Do you think you could find a workaround?

If not, i think we could nly manage GROUPS :

groups = roles (organizationalRole)
memberOf = roleOccupant


I cannot think of a workaround. There isn’t an obvious solution for you situation, other than changing the names of the OUs.

What do you mean?


I mean that we may not be able to use DEPTS based on OU but we will create groups into LDAP and sync them to Seafile GROUPS


Hi @Jonathan

Sorry to insist, but considering the ObjectClasses of the Ous

dn: ou=epcc-pole-numerique,o=epcc,dc=domain,dc=ext
ou: epcc-pole-numerique
objectClass: organizationalUnit
objectClass: top
objectClass: gosaDepartment

dn: ou=people,ou=epcc-pole-numerique,o=epcc,dc=domain,dc=ext
objectClass: organizationalUnit
ou: people


the FILTER selects OnlyobjectClass: gosaDepartment


the scope search is Subtree

I suppose you could catch the user


Directly below ou=epcc-pole-numerique

Am i right ?

BTW, FILTER on OUs may be useful, right ?



@gauburtin If all the OU’s you want are with the same objectClass, it’s possible to design an option to only sync these OUs into Seafile. But just to be clear: what you need from this option is that OUs not with specific objectClass will be bypassed. All users under such OUs will be added as members to its parent OU? e.g. will be directly under epcc-pole-numerique?


Good news, its a first step :wink:

Yes, this is the expected behaviour.
I was considering that subtree search could do the job easily, but i may be wrong.


It cannot be simply done with subtree search. When do you need this feature?



I would say in april :thinking:

Do you think it is possible ?


I think that’s okay. We’ll put it into the plan.


Thank you @Jonathan