[kronolith] editing shared calendar properties

[Jens-U. Mozdzen]

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...

>> 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 :).

Regards,
Jens