243919 - Wanted: Read-only option for remote calendars.

Status: RESOLVED DUPLICATE of bug 310503

(Calendar :: General, defect)

Description

[Joel Hedlund]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

The "Subscribe to Remote Calendar" should have and option that says "Read-only
Calendar" to prevent users from (accidentally?) adding events to remote
calendars that they don't have any PUT-priviliges to.

Reproducible: Always
Steps to Reproduce:
1. Subscribe to a GET-Only WebDAV remote Calendar
2. Add some events to it.

Actual Results:  
Events are added to the local file. These will be removed silently at the next
remote refresh.
See also bug 243918.

Expected Results:  
The "Subscribe to Remote Calendar" should have and option that says "Read-only
Calendar" to prevent users from (accidentally?) adding events to remote
calendars that they don't have any PUT-priviliges to. Users should not have the
option to add events to such a calendar. Possibly, Mozilla Calendar could also
provide an option to check the GET/PUT-ability of a Remote Calendar at
Subscribe-time, and check the Read-only option by default if is unable to GET
what it PUT.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

Isn't this something that should be done at the server level?

Comment 2

[Joel Hedlund]

(In reply to comment #1)
> Isn't this something that should be done at the server level?

No! The server is not the problem here. You can very well (and in fact you
should!) restrict the PUT priviliges on the server so that the individual users
only have PUT priviliges on their own remote calendars, and possibly so that
they have GET priviliges on each other's remote calendars. The problem which I'm
referring to is that the Mozilla Calendar application lets the user modify the
*local* Calendar file, even though he or she is not allowed to update the remote
file. The result is that the newly added events are lost in the next refresh
operation. Furthermore - if this refresh operation is the automatic refresh of
remote calendars that occurrs at program startup - chances are that this removal
will go unnoticed, and consequentially it is very likely that you (the user)
will miss that important meeting, just because you accidentally put it in the
wrong calendar file. The reason we want synchronized calendars is that we don't
want this thing to happen, and this is excactly why there should be a read-only
option for remote calendars that you don't have PUT access to. Hope I made
myself clear this time. 

Cheers!
/Joel Hedlund

Comment 3

[Joel Hedlund]

Altered severity from "Enhancement" to "Critical" due to the risk for data loss
that is involved in this bug.

Comment 4

[Justin Wood (:Callek)]

Just as a rough guideline on stuff that needs to be done to support this:

Disabling of "Read-Only" Menu items (or removal) in the "New Event" (and "New
Tasks") dialogs.

Disabling of ability to change calendar name (?)

Disabling of ability to delete (local) event in the Read-Only calendar.

UI in the subscribe dialog to dictate that it is read only, and/or a test on
subscription itself to 'check' if it is a read-only remote file [If server/file
system doesnt prevent it, should we?)

I'm not tackling this yet, though thats just a rough guideline of things to
change to solve this bug.

Comment 5

[Joel Hedlund]

(In reply to comment #4)
> Disabling of ability to change calendar name (?)
Can the calendar name be set in the .ics file, or do you propose a new file
(-format)? The user would otherwise have to specify a name for the calendar
anyway at subscription time, and I'd think it would be frustrating not to get to
change it later.

Otherwise I think you summed it up pretty good. Thanks again for a great
application. It will no doubt be very helpful for us.

Comment 6

[Arnout Engelen]

(In reply to comment #4)
> Disabling of ability to delete (local) event in the Read-Only calendar.

Obviously, not only deleting but also modifying (local) events should be disabled.

Comment 7

[Alin Derom]

*** Bug 299836 has been marked as a duplicate of this bug. ***

Comment 8

[Simon Paquet [:sipaq]]

*** Bug 299836 has been marked as a duplicate of this bug. ***

Comment 9

[Joey Minta]

*** Bug 310079 has been marked as a duplicate of this bug. ***

Comment 10

[Robin Edrenius]

Resolving as duplicate of Bug 310503.

*** This bug has been marked as a duplicate of 310503 ***