[kronolith] editing shared calendar properties

[Jens-U. Mozdzen]

Zitat von Jan Schneider <jan at horde.org>
>>>> If it's detected by checking that the resource is in the (current  
>>>>   user's) personal name space, then nobody ever would be the  
>>>> owner:   The resource is only available under "shared".
>>>
>>> That would most logically map to "system calendars" in Horde then. We
>>> can override permissions on other share backends than Kolab to   
>>> allow  administrators access to non-owned system calendars. This   
>>> won't work  with Kolab backends, because it depends on ACLs. We   
>>> might those folder  still consider system calendars, but also   
>>> requiring admins to have  sufficient ACLs. But that's not   
>>> implemented currently.
>>
>> From how I read it (I'm far from an expert), IMAP annotations can  
>> be  "shared" or private. In the context of this discussion, it  
>> would  mean that a user can set one's own annotation (private) when  
>> granted  appropriate access, while there may be a shared  
>> annotation, like  "the default properties". Would it be feasable  
>> for future versions  to support something like "user-individual  
>> overrides" for such  properties across all back-ends, which then  
>> would i.e. be mapped to  private annotations in case of IMAP? I  
>> believe that especially  display properties should be settable in  
>> the realm of each user...
>
> This has nothing to do with the problem. As long as the current user  
>  doesn't have sufficient ACLs for a folder, he can't see or change  
> its  annotations.

As I'm changing those annotations as my user (not admin) all the time  
(via cyradm), and I see changes in Horde's behavior, it seems I  
actually do have permission to change it. All that is missing is some  
UI functionality that will let me make the changes without creating  
that base64-encoded nested structure myself.

BTW, even the code mentions that private annotations might actually be  
in order:

--- cut here:  
/usr/share/php5/PEAR/Horde/Kolab/Storage/List/Query/Share/Base.php ---
class Horde_Kolab_Storage_List_Query_Share_Base
extends Horde_Kolab_Storage_List_Query_Share
{
      /** The folder description */
      const ANNOTATION_DESCRIPTION = '/shared/comment';

      /** The share parameters */
      /** @todo Shouldn't this be private data? */
      const ANNOTATION_SHARE_PARAMETERS = '/shared/vendor/horde/share-params';
--- cut here ---

which is where I suggested that two-stage approach: use shared  
annotation (if available) as a default, and give the user a chance to  
override (as a private annotation if the ACLs permit it... or store  
those overrides in the user's settings, separated from the shares).  
It's more of a general design decision, UI-wise: If a user needs some  
specific display setting, other than that selected by the owner of the  
share, let that user make that setting. Think of visually impaired  
people, that may need more contrast or cannot distinguish certain  
colors; no need to inflict their limitations to all users, but otoh  
there's no reason to make their work harder or impossible because  
someone not impaired didn't take that into account.

>>>> If the above is true, then I'd have no current way to edit the    
>>>> properties, but manually. Could you point me to a place (in the   
>>>> code  or docs) where I might find out the structure of the   
>>>> "share-params"  attribute? As you probably have already  
>>>> determined  from my quoted  value above, my manual approach  
>>>> currently only  tries to set the  display color, which did not  
>>>> show any effect  after re-login to  Horde/kronolith.
>>>
>>> It's a serialized PHP array, spotting the color field should be easy.
>>
>> Yes it is, and that's what I tried with the annotation I set   
>> manually ("share-params:   
>> YToxOntzOjU6XCJjb2xvclwiO3M6NzpcIiMwMGZmMDBcIjt9", which decodes to  
>>  "a:1:{s:5:\"color\";s:7:\"#00ff00\";}"). Unfortunately, this had   
>> absolutely no effect (color is still #dddddd), so I had guessed  
>> that  the other fields were important, too. I'll see if I can find  
>> the  place this is read and try to find out what I did wrong :).
>
> It's more likely that the old value is still cached in Horde.

Seems like it's not as easy as that: Whenever I only set the color  
attribute, now (krono 4.0.3) I get an error - looks like I must set  
the "share-name" element too, which in itself is again base64. I've  
tried to set
a:3:{i:0;s:8:"jmozdzen";i:1;s:16:"shared.urlaubnde";i:2;s:1:"/";}
and other variations, but have not yet been successful. The above  
value i.e. still leads to a PHP error message

PHP ERROR: array_merge(): Argument #1 is not an array [pid 10705 on  
line 342 of "/usr/share/php5/PEAR/Horde/Share/Kolab.php"]

and the calendar list (left pane of kronolith screen) isn't loading at  
all. Caching seems not to be the problem - I log off, stop apache,  
empty H5 cache, start Apache, log in. Of course, once I completely  
delete share-params, I'm error-free but back to square one.

My share-params value for INBOX/Kalender looks like (decoded):
a:5:{s:6:"source";s:5:"kolab";s:11:"fbrelevance";i:0;s:9:"xfbaccess";a:0:{}s:5:"color";s:7:"#00ff00";s:10:"share_name";s:80:"YTozOntpOjA7czo4OiJqbW96ZHplbiI7aToxO3M6ODoiS2FsZW5kZXIiO2k6MjtzOjU6IklOQk9YIjt9";}

where "share_name" decodes to  
"a:3:{i:0;s:8:"jmozdzen";i:1;s:8:"Kalender";i:2;s:5:"INBOX";}". I  
assume the first to be the owning user (I've seen "user at domain" format  
for some newly create shared folder, too), the middle value the name  
of the shared folder within the name space, and the last value to be  
the name space. Do you have some hint for me what it should look like  
for the "shared.urlaubnde" resource? (Yes, my calendar is actually  
with "/", the shared one with ".", verified via cyradm).

Thank you for any insight or any other help you can share.

Regards,
Jens