r40051: * API/accounts: instance-wide cache for account-data incl. members and memberships, so change take imediate effect (compared to previous session based cache)
r40052: not storing $GLOBALS[egw_info][user] twice in session (was also stored as $GLOBALS[egw]->session->user), also removing not used $GLOBALS[egw_info][user][acl], but re-reading preferences in session::verify() so long running sessions get preferences set by an other session, removing nowhere used creditspoint class from api (calls not public available creditspoint app)
r40053: * API/preferences: caching preferences in instance cache instead of session, to get immediate update in long running sessions (eg. sync) and get smaller sessions
- fixed typo / wrong direction of conversation when storing contacts
- fixed accounts_sql, which uses addressbook_bo::search() to convert created and modified timestamps to servertime as
- (documented that) accounts class (SQL and LDAP) operate completly in server-time
- calling static methods static: accounts::cache_invalidate() or egw::invalidate_session_cache()
- fixed wrong number of deleted items in setup_cmd_ldap sub-comand=delete_ldap
- only use create, if we have an ldap_admin_pw set
- call an add_account hook for each created account, if specified (not by default)
It turned out to be a caching problem, as the cache of the accounts-class still contained a failed id2name resolution for the new account.
This was caused by the session-restore with stored the cache in the global accounts object ($GLOBALS[egw]->accounts) too.
Now the global cache is in the global account-object and all other account objects use just a reference to that cache. It get stored from common::egw_final by calling $GLOBALS[egw]->accounts->save_session_cache() in the session."
- new cleaner AND documented interfaces
- old interfaces are still availible, but depricated
- LDAP backend stores now membership information in LDAP too, and does NO longer require the phpgwAccount schema
- LDAP backend deals now well with LDAP schema in which posixGroup is no structural object (eg. newer SuSE distros)
- password from users are done now binded as that user, so if you dont need/use our admin to manage accounts, you can give a root-dn which only allows to search&read accounts
- phpgw_accounts --> egw_accounts
- phpgw_acl --> egw_acl
- phpgw_log(_msg) --> egw_log(_msg)
- phpgw_config --> egw_config
- phpgw_applications --> egw_applications
This requires code-changes in many apps. Quite often I was able to replace the db access, with calls to the appropreate classes.
