cannot add ACLs to kolab's default tasklist "Aufgaben" (German)

i am using kolab-2.1 and horde-webmail-1.1rc1 i cannot ad

Tue, 25 Dec 2007 23:59:55 +0000

i am using kolab-2.1 and horde-webmail-1.1rc1 i cannot add ACLs to kolab's default tasklist "Aufgaben" (German), the php error says: Fatal error: Call to a member function get() on a non-object in /usr/local/share/_horde-versions_/horde-webmail-1.1-rc1-netzwerkteam/services/shares/edit.php on line 67 i have tracked the issue down to lib/Horde/Share.php and with kolab my fix now works fine, not sure about other backends... diff -ur horde-webmail-1.1-rc1/lib/Horde/Share.php horde-webmail-1.1-rc1-netzwerkteam/lib/Horde/Share.php --- horde-webmail-1.1-rc1/lib/Horde/Share.php 2007-11-29 12:32:53.000000000 +0000 +++ horde-webmail-1.1-rc1-netzwerkteam/lib/Horde/Share.php 2007-12-25 23:57:02.000000000 +0000 @@ -212,7 +212,7 @@ } $share->setShareOb($this); $name = $share->getName(); - $this->_cache[$name] = &$share; + $this->_cache[$name] = $share; $this->_shareMap[$cid] = $name; }

What you are doing there is breaking object references - whi

Wed, 26 Dec 2007 04:25:00 +0000

What you are doing there is breaking object references - which almost certainly is not the fix; we need to find out why doing that fixes things in your case. What PHP version are you using? What is $share when it's assigned there, and then later on the error, what is it both with and without the reference?

the return value of Horde_Share::&getShareById() as in horde

Wed, 26 Dec 2007 14:21:29 +0000

the return value of Horde_Share::&getShareById() as in horde-webmail-1.1rc1 returns a string: "INBOX/Aufgaben" (which is the kolab user default task folder in Germain).

> What PHP version are you using? php-5.4.2-2 as current

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

> What PHP version are you using? php-5.4.2-2 as currently in debian unstable > What is $share > when it's assigned there INBOX/Aufgaben (already added this as a comment... sorry for the redundancy) > and then later on the error, what is it > both with and without the reference? what exactly do you mean by this? can you give a clue on where to put my debug prints and var_dumps? mike

i have played around with it a little more. i have replac

Wed, 26 Dec 2007 15:42:35 +0000

i have played around with it a little more. i have replaced the original method in lib/Horde/Share.php: function &getShareById($cid) { if (!isset($this->_shareMap[$cid])) { $share = &$this->_getShareById($cid); if (is_a($share, 'PEAR_Error')) { return $share; } $share->setShareOb($this); $name = $share->getName(); $this->_cache[$name] = &$share; $this->_shareMap[$cid] = $name; } return $this->_cache[$this->_shareMap[$cid]]; } by my own debug version (what it does: do not use _cache, but update _cache): function &getShareById($cid) { $share = &$this->_getShareById($cid); if (is_a($share, 'PEAR_Error')) { return $share; } $share->setShareOb($this); $name = $share->getName(); $this->_cache[$name] = &$share; $this->_shareMap[$cid] = $name; return $share } this debug method raises the same error... BUT!!! if i comment out one line in my this debug method, it suddenly works (although on the first spot this does not make sense...): function &getShareById($cid) { $share = &$this->_getShareById($cid); if (is_a($share, 'PEAR_Error')) { return $share; } $share->setShareOb($this); $name = $share->getName(); $this->_cache[$name] = &$share; /* * $this->_shareMap[$cid] = $name; */ return $share } and the return value of the original getShareById() method is exactly what is stored in $this->_shareMap[$cid] ("INBOX/Aufgaben", "INBOX/Aufgaben (PRIVAT)", etc. i.e. the corresponding share name). is it possible that $this->_cache[$name] and $this->_shareMap[$cid] refer to the same data structure???? weird things going on in php... BTW: where is the _shareMap stored? datatree, php session, filesystem? hope this helps... mike

> BTW: where is the _shareMap stored? datatree, php session,

Wed, 26 Dec 2007 15:47:38 +0000

> BTW: where is the _shareMap stored? datatree, php session, filesystem? It's just an array, it's not stored anywhere except for in memory during a single page request. It helps prevent duplicate fetching of a single share during one page load. Can you try turning off suhosin? It's been the weak link in a lot of broken PHP behavior we've seen.

> Can you try turning off suhosin? It's been the weak link i

Wed, 26 Dec 2007 17:00:54 +0000

> Can you try turning off suhosin? It's been the weak link in a lot of > broken PHP behavior we've seen. not sure how to do this. php.ini? or do i have to install a php5 with suhosin diabled (i.e. compile from source)? could not find any hints to that with google search...

It depends on how your PHP package is built - if it's static

Wed, 26 Dec 2007 17:02:37 +0000

It depends on how your PHP package is built - if it's statically compiled you need a different PHP build.

> It depends on how your PHP package is built - if it's stat

Wed, 26 Dec 2007 17:28:08 +0000

> It depends on how your PHP package is built - if it's statically > compiled you need a different PHP build. suhosin is loaded as an extension. the phpinfo page claims that suhosin is comiled into php5, but you can only configure it, when the suhosin.so extension is loaded... the bug occured already without php5-suhosin extension installed. now that it is installed, there is no change... hmmm...

> the bug occured already without php5-suhosin extension ins

Wed, 26 Dec 2007 17:49:24 +0000

> the bug occured already without php5-suhosin extension installed. now > that it is installed, there is no change... So you have uninstalled suhosin, restarted Apache, verified that suhosin is gone from the phpinfo page, re-tested, and still have the issue?

sorry for the delay. yes, i looked at it again toroughly. it

Fri, 28 Dec 2007 19:37:21 +0000

sorry for the delay. yes, i looked at it again toroughly. it is so!

Has this been fixed with the recent changes in CVS? From the

Mon, 03 Mar 2008 08:06:49 +0000

Has this been fixed with the recent changes in CVS? From the error report I assume it is the same kind of problems since the arrays were messed up in the Kolab driver. Closing for now, please reopen if the problem persists.

hi gunnar, > Has this been fixed with the recent changes

Tue, 01 Apr 2008 09:56:46 +0000

hi gunnar, > Has this been fixed with the recent changes in CVS? From the error > report I assume it is the same kind of problems since the arrays were > messed up in the Kolab driver. Closing for now, please reopen if the > problem persists. no, the problem remains... in only remembered this request today and tested it... mike

however, the php error is slightly different now:

Tue, 01 Apr 2008 09:58:06 +0000

however, the php error is slightly different now: Fatal error: Call to a member function getACL() on a non-object in /usr/local/share/_horde-versions_/horde3-kolab-cvs/horde/lib/Horde/Share/kolab.php on line 1451

hi gunnar, here is a var_dump of the object that causes t

Tue, 01 Apr 2008 10:10:49 +0000

hi gunnar, here is a var_dump of the object that causes the error (_imap points to NULL!?!?)... is the ImapFolder_Permission constructor call faulty? object(ImapFolder_Permission)#23 (7) { ["_folder"]=> string(23) "INBOX/Aufgaben (AIKIDO)" ["_imap"]=> &NULL ["data"]=> array(1) { ["users"]=> array(2) { ["m.gabriel@das-netzwerkteam.de"]=> int(30) ["c.music@das-netzwerkteam.de"]=> int(6) } } ["_owner"]=> string(29) "m.gabriel@das-netzwerkteam.de" ["datatree"]=> NULL ["name"]=> NULL ["order"]=> NULL } Fatal error: Call to a member function getACL() on a non-object in /usr/local/share/_horde-versions_/horde3-kolab-cvs/horde/lib/Horde/Share/kolab.php on line 1452 best, mike

Hi Mike, the location of the error does indicate that you

Thu, 24 Apr 2008 16:06:38 +0000

Hi Mike, the location of the error does indicate that your Share/kolab.php file does not seem to match Horde CVS. Are there any additional patches applied? If you use the current Share/kolab.php from FRAMEWORK_3 you should have the getACL call on line 1236. If you deactivate share caching, does the problem persist?

hi gunnar, > Hi Mike, > > the location of the error doe

Thu, 24 Apr 2008 22:32:23 +0000

hi gunnar, > Hi Mike, > > the location of the error does indicate that your Share/kolab.php > file does not seem to match Horde CVS. Are there any additional > patches applied? If you use the current Share/kolab.php from > FRAMEWORK_3 you should have the getACL call on line 1236. i use your external-horde-cvs.sh and: yes, indeed, i have the distlist patch in the Share/kolab.php. the corresponding location is line 1236 in vanilla FRAMEWORK_3. > If you deactivate share caching, does the problem persist? ahh... ok... it works when caching is disabled... mike

Fixed in CVS. Please retest with caching enabled and reopen

Fri, 25 Apr 2008 06:58:15 +0000

Fixed in CVS. Please retest with caching enabled and reopen if the problem persists.