users' kolab addressbook entries not editable

i am using kolab 2.1 (debian unstable), kronolith-2.2-rc1 fr

Mon, 24 Dec 2007 12:48:45 +0000

i am using kolab 2.1 (debian unstable), kronolith-2.2-rc1 from the horde-webmail-edition-1.1-rc1. with turba i can add entries to "My Contacts" (kolab-cyrus addressbook in user//Contacts), i can view them, i can even delete them. but: any modification of a contact item (adding mail address, phone number, etc.) is not stored in kolab-cyrus. works fine when editing contacts with kaddressbook... changes performed from kaddressbook are also immediately present in turba. best & merry x-mas, mike

did a bit of debugging... the problem is that with kolab

Wed, 26 Dec 2007 03:17:47 +0000

did a bit of debugging... the problem is that with kolab the source of kolab's default user contact folder is equal to the user's email adress. other non-default contact folders have the name of the cyrus path, e.g. INBOX/Contacts_private. So address book entries in non-default contact folders are modifiable... but not so the kolab user default contact folder... the issue originates in turba/lib/ListView.php and goes further down into turba/lib/Object.php. Everything rendered in ListView.php is passed on to further pages (view.php, edit.php, etc. by Variables::getDefaultVariables()) when rendering a table row (row.inc) in ListView.php, the method ob->getSource() (row.inc) returns INBOX/Contacts for the kolab user default contact folder, but should return user@domain. looking closely at the Turba_Driver::getSource() method in turba/lib/Object.php: function getSource() { return $this->driver->getName() } this should call the Turba_Driver::getName() method in turba/lib/Driver.php, which then - in a proper object oriented environment - should return function getName() { return $this->driver->name; } but it does not... or it does, but we have two different values for the same expression ($this->driver->name). anyway, find a patch attached, that works well with kolab, not sure about other backends...

> looking closely at the Turba_Driver::getSource() method in

Wed, 26 Dec 2007 03:25:14 +0000

> looking closely at the Turba_Driver::getSource() method in > turba/lib/Object.php: > > > function getSource() { > return $this->driver->getName() > } > > > this should call the Turba_Driver::getName() method in > turba/lib/Driver.php, which then - in a proper object oriented > environment - should return > > function getName() { > return $this->driver->name; > } > > but it does not... or it does, but we have two different values for > the same expression ($this->driver->name). I'm going to need to see some other info about what object is what for this patch to make sense. What PHP version are you running? Have you tried using debug_backtrace() and var_dump() on the objects involved to see why the $name property seems to differ?

i am using php-version 5.2.4-2 (as currently in debian testi

Wed, 26 Dec 2007 12:07:56 +0000

i am using php-version 5.2.4-2 (as currently in debian testing/unstable). i have sent a phpinfo page link to chuck directly for further reference... a table row for my kolab user default abook (INBOX/Kontakte) in html looks like this: Test Abookuser in the several hrefs the option "source" is passed to the contact.php script. once it says source=user%40mailserver.dom which works fine (renderer by ob::url() in row.inc). the other times it says source=INBOX%2FKontakte which breaks kolab/cyrus (rendered by ob::getSource() in row.inc). for more information on the related turba object i have sent a Var_Dump() of one $ob in row.inc to chuck directly. thanks, mike

What might be most instructive is to var_dump the $this->dri

Wed, 26 Dec 2007 15:43:29 +0000

What might be most instructive is to var_dump the $this->driver object in Object.php, and then put a var_dump($this) inside getName() in Driver.php. See if the two objects match. If you're posting object dumps please try to be selective as there are some recursive references that make things a bit repetitive. Also, please post them as text attachments to the ticket instead of mailing them to someone privately. Thanks!

this issue is gone in current horde cvs... please close the

Thu, 20 Mar 2008 19:48:24 +0000

this issue is gone in current horde cvs... please close the ticket.

Thanks.

Thu, 20 Mar 2008 22:01:15 +0000

Thanks.