[kronolith] shared calendar ownership attribute?

[Volker Schmidts]

Ralf Lang <lang <at> b1-systems.de> writes:

> 
> Hi users,
> 
> my company is using the new ajax kronolith and we're quite fond of it. We're 
> modelling teams (marketing, development) or issues (holiday, company events) 
> as calendars/shares with the team leaders or office staff as calendar owners. 
> 
> That said, access management is a little lacking. 
> 
> - Only one person can currently be the owner and thus manager of a calendar. 
> When a team has two managers and the wrong one is unavailable, calendar 
access 
> cannot be regulated.
> 
> - a person can only have edit/delete permission on all or none of the 
> calendar. Thus a person can either not delete his own entries or can by 
> accident delete/change other persons' entries.
> 
> The same roughly applies to other shares-based items such as tasks or address 
> books but it's most relevant with calendaring.
> 
> How do you tackle these issues in your installations?
> 
> If there is no practical solution, I'll probably add these items as feature 
> requests on bugs.horde.org.
> 
> gespannt,
> 
> Ralf
> 

Hi Ralf,

we have similar ideas on using kronolith here at our research group at a german 
university. I also tried to use shared calendars as a simplified means of 
resource management, thereby running into the same problems as you have with 
the permissions. As I understand it the resource management is not yet possible 
via the AJAX interface but works with the traditional interface, albeit 
somewhat cumbersome for our purposes.

The farthest I have come in this endeavour is by giving creators all 
permissions and authenticated users show and edit but no read permissions on a 
calendar. This way they are able to add new events and can edit their own but 
when trying to access the events of others due to the absence of read 
permissions they are denied. The drawback however is that only the creator (and 
in case of a non-system calendar also the owner) is able to see the details of 
the event - the others only see a "busy" slot where the event is scheduled. 

Strangely enough this setup only seems to work with the traditional interface, 
as in the dynamic one authenticated users can edit events created by others 
even without the read permission.

So, long story short: I also be interested should you find a practical solution 
to this problem.


Regards,

Volker