bug: the includegroups does not working

[0x0034]

such as, i'm sync user from im, like slack or dingtlak.

our company level tree as follows

companyA
--department-A
--department-B
--department-C
....

and theres gidnumbers as follows

companyA: 11
--department-A: 12
--department-B: 13
--department-C: 14

and the includegroups data as follows

1,11,12
2,11,13
3,11,14
4,11,15

but i'cant list user from ou=companyA my version is 2.3.0

Have you encountered anything similar?

Can you help me solve it? thx very much

[0x0034]

and if i have many companys to compose a group, i need a admin user to list any groups. but i'm try to add a external user , but it fallback a error like this

Search request basedn=dc=glauth,dc=com binddn= filter=(objectClass=subschema) scope=0 searchbasedn=cn=schema src=172.19.0.1:53034
Wed, 11 Oct 2023 17:58:55 +0800 INF handleSearchRequest error LDAP Result Code 50 "Insufficient Access Rights": Search Error: Anonymous BindDN not allowed

[Fusion]

I am merging a few PRs. As soon as Im done I'll check this. out

[Fusion]

I feel like I'm missing a few data points here. When you write that you are syncing your data from slack or dingtlak, do you mean that you are:

1. copying this data in a config.toml files?
2. replicating this data inside a SQL database?
3. or you are not, in fact, syncing, but are using GLAuth as a passthru between your client and e.g. dingtlak's LDAP endpoint?

Depending on #1, #2, #3, this would mean that your schema lives in a very different location.

[0x0034]

noop, i'm using mysql as my backend, and im migrate the db struct as the plugin migrate. and i promise the db struct is exactly the same.
i'm sync user data from slack or dingtalk to db.

[0x0034]

if you need

I feel like I'm missing a few data points here. When you write that you are syncing your data from slack or dingtlak, do you mean that you are:

1. copying this data in a config.toml files?
2. replicating this data inside a SQL database?
3. or you are not, in fact, syncing, but are using GLAuth as a passthru between your client and e.g. dingtlak's LDAP endpoint?

Depending on #1, #2, #3, this would mean that your schema lives in a very different location.

If necessary, I can desensitize the data and throw it out.

[Fusion]

If you wouldn't mind sending it to my yes please. Send it to cfr@altmails.com thanks.