Hi all
[and especially @daniel.pan and @Jonathan)
Could it be possible to implement one more feature in DEPT SYNC as :
DEPARTMENT_FILTER
as GROUP_FILTER
We have an LDAP STRUCTURE in which
o=epcc
ou=epcc-pole-numerique
ou=people
ou=groups
ou=roles
As it is shown below
Id’like to filter these because as a user i see two groups
epcc-pole-numerique
people (i’m in people)
I don’t want to show “people” group
[Edit]
You may also SYNC ONLY Departements that contains on LDAP object as defined in USER_OBJECT_CLASS
Then, empty departments would not be imported
Regards
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: https://manual.seafile.com/deploy_pro/ldap_group_sync.html
1 Like
Thank you @Jonathan
Please consider that the filtering option should only bypass some OU for the display
Considering the following LDAP structure
o=epcc
ou=epcc-pole-numerique
ou=people
ou=groups
ou=roles
Users are located in the branch people
The DEPTs should be
eppc
epcc-pole-numerique
And users that are in epcc/epcc-pole-numerique/people should be located in
epcc
epcc-pole-numerique
Yes, i noticed that and it’s really nice !
Regards
1 Like
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 
regards
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
dn: uid=user.name,ou=people,ou=epcc-pole-numerique,o=xxx,dc=domain,dc=ext
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
If
the FILTER selects Only objectClass: gosaDepartment
and
the scope search is Subtree
I suppose you could catch the user
dn: uid=user.name,ou=people,ou=epcc-pole-numerique,o=xxx,dc=domain,dc=ext
Directly below ou=epcc-pole-numerique
Am i right ?
BTW, FILTER on OUs may be useful, right ?
regards
@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. user.name will be directly under epcc-pole-numerique?
Good news, its a first step
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?
Hi,
I would say in april 
Do you think it is possible ?
I think that’s okay. We’ll put it into the plan.
