New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No tickets are visible #461
Comments
Interesting. But we did modify the LDAP Sync behaviour in 7.0.8.
Do you have LDAP role sync in place? |
Yes, we have LDAP Sync in use. How should I modify my config? |
Good question. We modified the Role / Group Sync to remove all roles a user is not in. We updated the handling, so that if a LDAP user is not assigned to a role / group and RoleSync is in place, that the roles are removed. So if you use Role Sync for you users, they have to be in the correct roles. You can see which roles / sync is applied at the moment of the login, if the MiniumLoglevel (Sysconfig) is set to notice/info or debug. Hope that helps |
I am wondering. All agents are members of roles. All roles are linked to groups and all groups are linked to queues. But only a few agents were removed from the roles. I have to make a test installation to debug, in order to not disturb our live system. |
I would start with the logins. |
I will try it. |
Can you please help me where to adjust this setting? |
Hi, the log level can be modified in the sysconfig: MinimumLogLevel |
Hi, this is not strange. Let me try explain (it would help to have your config here btw). I would guess you have your LDAP Auth after your DB Auth.
So LDAP is checked after DB.
Do you have an active role sync setting somewhere? My guess, again - without you config it is hard to check, is that the permissions have been removed and they need to be restored. I can offer community support to help here, if needed. |
I have I have nothing with I have I have configured neither a role sync nor a group sync "Downgrading will not restore the permissions, but the behaviour." This is what I observed. I had to rebuild the permissions after reverting to 7.0.6 (this is, what I wrote in my first post) |
@schnudd31do3 I will try to verify this and get back to you with a fix if needed. |
The "2. DB is checked first ->Wrong PW" is becauce the PW was not found in the DB. LDAP-user's PW are not stored in the DB because of not syncing. The DB is only used for storing credentials of none-LDAP-users (e. g. admin). |
Correct, and as long as the order is DB->LDAP you will always get this info, because we can not know where a user is coming from / is stored. We always have to check all backends until the login is OK or the chain ends and we do not allow access. |
I checked LDAP with "ldapsearch -x -H ldaps://xy.z/ -D [me]@XXXX.XX -W cn=user -d 9" No errors detected, here is the STDOUT:
|
@schnudd31do3 I'm sorry, but what should us tell this? |
I tought, that the log perhaps could help to clearify what was going wrong during LDAP autentication. |
Who said that something is wrong with the authentication? You have a problem with authorization and this is what I currently verify. |
Thanks, but not needed. The problem is not the Auth itself, but (probably) a bug in the change we introduced in 7.0.8. We update the issue when we have an update on this. |
@hanneshal :Thanks for your friendly explanation. |
Today I updated to V 7.0.9. After that, my tickets remain in my view and my permissions remain unchanged. I keep on observing. |
Environment
Expected behaviour
All my tickets should be shown in any order (e. g. sorted by open, queue, reminder, ..)
Actual behaviour
How to reproduce
Additional information
The logfiles in /opt/znuny/var/log/Deamon/[...ERR].log are there, but they are all empty. The znuny.log.2023-07 does not show any regarding errors.
Screenshots
The text was updated successfully, but these errors were encountered: