Classification of a calendar components

[niakouais]

hello all,
First, nice work for this project. I use Radicale 0.8 on my synology with SSL, python 3 and access by rights file and it works well. On client side, I use android with CalDav Sync Free Beta and my Ipad.

It does exist the property CLASSIFICATION that can be PUBLIC or PRIVATE on a iCalendar (RFC5545).It might be used in different ways but this property is widely used. (very convenient on outlook in my office)

Would it be possible to filter "CLASS:PRIVATE events" when displaying on read-only accounts. In other words, it would be great to limit "CLASS:PRIVATE events" to the owner of the calendar.

What do you think ?

Have a nice day.

[liZe]

It's a nice feature, but I'm afraid it's a bit big for 2.0 😞.

[bigbig6]

Hi,

This one of the most important feature missing in Radicale...
Hope it would be implemented soon.

Regards,

Big

[bigbig6]

Hello,

Is possible to implement it?

Thank's.

Regards,

Big

[Unrud]

Is possible to implement it?

No

[bigbig6]

Love this kind of answer...

The classification of 'private' or 'public' is stored in each elements.
It is so complicated to show only elements in a calendar that are marked as 'public'? Maybe we need another right like public or 'p' in the right management. It may be a more restricted conditions than the read permission.

I would think it is just another condition for display calendar elements.

Regards

Big

[Unrud]

It is so complicated to show only elements in a calendar that are marked as 'public'?

Radicale doesn't have proper support for sharing calendars. (You can kind of make it working by using symlinks and a custom rights file.) Without calendar sharing this feature is kind of useless.

It is so complicated to show only elements in a calendar that are marked as 'public'?

Why don't you use separate calendars for private and public events? With separate calendars you can also use different colors for events. (Some clients don't visually distinguish private events, you have to open the event in the editor to even see that is is private.)

Maybe we need another right like public or 'p' in the right management.

I would rather like to get rid of the rights management. If you give another user access to one of your calendars, it doesn't show up in clients (or the web interface). You can only access it directly by URL, which is not supported by many clients.

Love this kind of answer...

The feature has very low priority. I would like to see support for "real" calendar sharing first.

[jaesivsm]

It is so complicated to show only elements in a calendar that are marked as 'public'?

Radicale doesn't have proper support for sharing calendars. (You can kind of make it working by using > symlinks and a custom rights file.) Without calendar sharing this feature is kind of useless.

Out of sheer curiosity, and because the feature interested me at some point, I'm wondering : is it because the relationship between user and calendar is guessed more that written down ? Am I wrong saying you would have to set a strong relationship between users and collection to implement such a feature ?

[bigbig6]

I can understand the need of supporting sharing calendar.

But you can also use rights management in order to have this share.
We can use another calendar with a different login (eg access to /user1 with the login/password of user2).

Actually, rights a defined in a file with read and write.
We can add a 'p' (public) right in order to see only public elements on readonly.

Using another calendar would be more difficult for standard users.

thank's

Big

[Unrud]

But you can also use rights management in order to have this share.

Yes, you could. I just don't think that it's worth it to put any effort into extending the rights management, because of its short comings. Once we have support for "real" calendar sharing, it should be easy to add this feature to it.

We can use another calendar with a different login (eg access to /user1 with the login/password of user2).

This only works with clients that let you enter the URL (e.g. http://localhost:5232/user1/calendar.ics) directly. If you login with user2 into clients like DAVdroid, InfCloud, iCal or the built-in web interface, the calendar /user1/calendar.ics can't be accessed.

Using another calendar would be more difficult for standard users.

I don't think so. To my knowledge, it's easy to work with multiple calendars in all clients. Creating new calendars in clients or the web interface (and then adding it to the client) also isn't difficult.

Out of sheer curiosity, and because the feature interested me at some point, I'm wondering :
is it because the relationship between user and calendar is guessed more that written down ?

Why would you need the user for this? You need to change storage.BaseCollection and storage.Collection to be able to pass it the "access mode" (e.g. "read"/"write"/"public"). In the case of "public" you have to filter out all private items, when get, list sync or serialize is called. Additionally, you have to add the "public" mode (which is basically equivalent to "read") to the rights management.

[bigbig6]

Is there a planning for calendar sharing?

Thank's.

Regards,

Big

[Unrud]

Is there a planning for calendar sharing?

It might take some time.

[dawidmachon]

any chance for that sharing? :)