361028 - Events where I am not the owner from can be moved

Status: NEW

(Calendar :: Calendar Frontend, enhancement)

Description

[Christian Jansen]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; (R1 1.3); .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: 

Events where I am not the owner from can be moved or resized in the calendar views.

Reproducible: Always

Steps to Reproduce:
1. Subscribe to an external calendar, or in WCAP case get an event by invitation
2. Select the event in one of the calendar views
3. Drag & drop to another location

Actual Results:  
The event can be moved, or resized.

Expected Results:  
The event should stay at its intended time slot

Comment 1

[Stefan Sitter [:ssitter]]

Isn't this a wcap provider bug because the provider should check if the calendar is read-only or not before editing the event/task?

Comment 2

[Damian Szczepanik]

I think Stefan is right, do we really want to support it?

Comment 3

[Bas van den Bosch]

I don't think so for now anyway. Rights-management in win is difficult. What if I want my secretary to be able to reschedule meetings for me, or perhaps my gf and my secretary? If you want to impose restrictions, you should do this at server-level (or in case of local files on file-level). I know exchange does this, you can impose read-only on webdav-files and communigate supports this but I don't think there's an RFC for this and it will be a hell of a job to support this for all different servers. If server-providers (such as MS and Communigate) want to support access-control through SB, they should write their own plugins (Imho).

Comment 4

[cmtalbert]

QA Discussion -->
There are many levels of access control that are possible, especially given the number of servers that we will support.  However, there may be some small number of things that we *will* want to support.

-- Some Simple Access Control that we might want --
* Read Only calendar support - we already have a fairly decent implementation of this.
* If the "organizer" attribute is set on an event or task, we probably want to display some kind of notification to the non-organizer user when the non-organizer user attempts to edit the bug. If all of iTIP is implemented, then that notification would take the form of "Do you want to notify the organizer of your changes?" and the user could say yes or no.  Even *without* iTIP implemented, we might want to display a message stating "This event was organized by X, are you sure you want to make this change?" and that might have been all Christian was looking for in his test above
* Likewise, if you are the organizer and you add/remove attendees or modify the event, you would want some kind of notification alerting you to this fact, and offering to send an update to the attendees (bug 334681)

-- Server side access controls --
* If the server supports some standard means of access control (I believe something along these lines is in the works for the CalDav spec) then we should ascertain what forms of access control are required for shared/published calendars.  At the very least we can ask if the calendar should be shared/published as read only or not.
* More complex server-specific access control - this is the type of control that Bas van den Bosch outlined in his comment above. Who does it get shared to and how.  As he noted, this will probably have to be solved on a provider by provider basis, but there will likely be similar interfaces and dialogs needed, and we should give thought to that if we develop this capability for our current  providers.
 

Comment 5

[Philipp Kewisch [:Fallen][☁️📆]]

> * Read Only calendar support - we already have a fairly decent implementation
> of this.
We already support not allowing to move such events. If this works nevertheless, I think we have a regression bug open on it.

> * If the "organizer" attribute is set on an event or task, [and you are not
> the organizer] ...
I believe right now its also not possible to move such events. Delegation support might change this, but thats also in a different bug.

> * If the server supports some standard means of access control ...
I believe inverse has some form of ACLs implemented that we could use.

I'm leaving this bug open for now since it contains some valuable information, but we probably have other open bugs that actually take care of these issues.