Map User Groups broken on module users_ldap_groups with Odoo 8 about server-tools HOT 11 CLOSED

did you check the box 'Only ldap groups'? If not, this is the expected behavior

from server-tools.

Note: this flag causes all group memberships being wiped on login and reconstructed from ldap group mappings, so you need a group mapping for all groups the user should have

from server-tools.

Yes, I checked it. I also put a log in the first line of get_or_create_user() that is where such function should be called to check if at least that function was being invoked or not. And is only executed the fist time the user logs (new user)

from server-tools.

Odoo's algorithm here is that it first uses the given credentials to do a local login, and if this works, never arrives at the ldap part, cf. https://github.com/OCA/OCB/blob/8.0/addons/auth_ldap/users_ldap.py#L252 - this means it's crucial that the local login fails, any possibility the user in question gets her local password changed to the ldap password by some mechanism? Check the user's password and password_crypt columns in the database.

from server-tools.

in case this happens because the users "change" their passwords via Odoo's UI, #287 might come to rescue

from server-tools.

So, if I undertand this right. When an user is created via auth_ldap their credentials are stored inside Odoo's database and the next time it logs Odoo don't checks the LDAP but the Odoo database for the password???

I have tested to change the password from inside the Odoo web interface for an user that was automatically created by the auth_ldap module.

Now I can log with both passwords (the one from LDAP, and the new that I changed inside the Odoo interface).
But checking the logs, I see that no matter with password I use to log, none of the passwords triggers a call on get_or_create_user() from users_ldap_groups/users_ldap_groups.py

Is there any way to avoid Odoo storing any password and always checking the LDAP and also always triggering a call get_or_create_user() ?

from server-tools.

No, you don't. The ldap module doesn't store the password. But the only way I can imagine for the behavior you describe is that the password ends up in the database via some other way.
The call should always be triggered for ldap users as they are supposed to have no password set, see the code I linked. Maybe some other module interferes with this mechanism?
Just put a breakpoint at the line mentioned above and debug through to see what's going on.

from server-tools.

The password is not ending in the database. I have just checked it manually.
I have deleted my user, and logged again with the LDAP password. get_or_create_use is executed this time (the first login), but never again if i logout and re-loing.
The database contains

# su postgres -c pg_dumpall|grep clopez
56  t   clopez      1   57  1   2016-02-03 15:22:27.166941  2016-02-03  1   2016-02-03 15:22:27.166941  \N  \N  \N  56  t\N f   t

If now I change my password form the Oddo interface, I can log with any of the passwords (the new one and the LDAP one). The function get_or_create_use continues to not be executed.
But now the DB contains the new password

# su postgres -c pg_dumpall|grep clopez
56  t   clopez      1   57  1   2016-02-03 15:22:27.166941  2016-02-03  1   2016-02-03 15:26:29.975368  \N  \N  $pbkdf2-sha512$6400$WYtxrlXqfQ9BCOHcm/Me4w$4qj/HstAPF1C.Q00Y11J7r3t5WJ7YkLCXtXaJtHYgGjlULRdIajb/bPlS5/1AOR.1BbpqY7BG587UjixwVTzhQ   56  t   \N  f   t

from server-tools.

the latter part (about your local password) is expected. Then you're left with debugging

from server-tools.

But how I can debug if the function is not executed? I'm not familiar with Odoo to know how the hooks and plugins work .

The only thing I see on the logs when re-login (and I'm running already with Debug loglevel) is:

INFO odoo_db2 openerp.service.common: successful login from 'clopez' using database 'odoo_db2'

from server-tools.

run your odoo interactively (=in a terminal by starting ./openerp-server with the appropriate parameters, not via your system startup script), write import pdb; pdb.set_trace() in the line before https://github.com/OCA/OCB/blob/8.0/addons/auth_ldap/users_ldap.py#L252, and now you'll be dropped to a debug shell with every login. Then step through the super(...)._login function to see what's going on there. For whatever reason, it comes up with a user id, which it shouldn't in the case of ldap users.

A nice intro on how to use pdb can be found at https://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python

I suspect some other module to interact with this process. If you can't to the debugging part, create a new database with only auth_ldap and users_ldap_groups installed, verify that it works properly there, and successively install the other modules in your current database until you found the culprit. (this assumes that the other module in question doesn't mess this up server wide, that's a possibility too. Then go back to step 1)

from server-tools.