- 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
- User accounts are an own addressbook now
- every user and group (can) have an own addressbook
- for groups the accessrights no longer depend on the creator
- new acl for adding into an addressbook
- all addressbooks can be displayed together (eg. accounts mixed with personal and group AB's)
- some useful new fields (photo, private cellphone, ...) and some obscure ones have been removed
- db update puts all contacts in the owners personal addressbook (further manual migration tools will follow), thought the UI already allows to mass-move them into a group-addressbook
- group addressbooks in SQL are created by making a group-grant for addressbook (like filemanger)
- Warning: all import/export/xmlrpc/syncml stuff and other apps accessing the addressbook is broken until the contacts class in the API gets fixed!
- it depends on further updates of etemplate, phpgwapi, admin!
==> it's pretty cool (specialy the foto's), but NOT ready for a production server !!!
Admin can now define multiple addressbooks each with an own edit / view template and an own icon.
Atm. all Addressbooks are stored in one backend, but this will change soon^tm
- 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.
code logic was wrong and it was using an API method that is
also buggy => in file /egw/phpwgapi/inc/class.common.inc.php the method
cmp_version_long().
1) the code logic:
it get versions for the current app and for the api from file
(app/setup/setup.inc.php) and from DB.
it loops over this 2 apps (app, and api), and set a $_current to true or
false. this variable value is defined by the last app check in the loop
(the API) => then if your API version is up to date, your application
version is also. which was wrong for me. Well in the attached file i
change the code logic.
