[kronolith] editing shared calendar properties

[Jan Schneider]

Zitat von "Jens-U. Mozdzen" <jmozdzen at nde.ag>:

> Zitat von Jan Schneider <jan at horde.org>
>> Zitat von Jens-Uwe Mozdzen <jmozdzen at nde.ag>:
>>>
>>> pardon my ignorance, but in case of a resource created under   
>>> "shared", who'd be the owner? How might I find out (IOW, how does   
>>> Horde determine the owner)?
>>
>> What does "shared" mean anyway, is that the public namespace?
>
> I can only say "it seems so" - I selected to create "a shared  
> folder" in Kolab and it appeared under that name space.
>
>>> If it's the user that created the share ("IMAP directory"), that'd  
>>>  be the special Kolab user that is defined as the Kolab admin...  
>>> and  is defined to Horde as an admin as well. Since it's the Horde  
>>> admin,  that user cannot access the kronolith dialogs to edit the  
>>> folder  properties: When I log in to Horde as an admin, all other   
>>> applications but Horde itself are unavailable.
>>
>> This is on purpose, though I don't know why.
>>
>>> 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.

>>> 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.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/