Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared "☑️ can edit" (within NC) calendar titles break if class:confidential and edited by subscriber #4044

Open
paradeiser opened this issue Mar 11, 2022 · 9 comments
Labels
0. to triage Pending approval or rejection bug

Comments

@paradeiser
Copy link

paradeiser commented Mar 11, 2022

Steps to reproduce

  1. Create User A and B
  2. User A shares a calendar with user B, checks "can edit" option
  3. User A creates an event "Test-Event" and sets visibility to "when shared show only Busy" (class:confidential)
  4. User B sees this event in his Calendar as "Busy" (instead of "Test-event")
  5. User B edits this event (e.g. shifts time)
  6. The event title also changes for the originating user A set to "Busy" hence, the original title vanished.

Expected behavior

I would expect:
6. The event title stays the same for the originating user A "Test-Event", with the new time or edits done by B.

Tho, I think this work-flow is contra-intuitive. It also does not reflect the common work-flow of google-calendars.

If a calendar is shared with "can edit" rights, I would expect this user also to see all details for "show as busy for others" events.
What sense would it make to be able to edit an event, I don't even know it's title.
Then the original title would not be obscured and user B could edit with the original title, hence it would also not be lost for user A.
The setting "When shared, show as" should actually state: "When shared to read-only users, show as busy"

One could discuss how to handle "hidden" (class:private) events.
Option 1) Don't even show to subscribers with "can edit" rights.
Option 2) Also show to "can edit" subscribers and let them actually edit this event too.
I personally would prefer option 1. This way you still have a way to entirely hide events from subscribers, even with edit rights.
The visibility option would state "When shared, hide this event to everyone"

Actual behaviour

If a subscribing user edits an event set to "show as busy" from another user, the original title is overwritten (to "Busy") also for the original user.

Edit: It breaks all event details, not just the title…

Calendar app version

3.2.0

CalDAV-clients used

NC Webinterface

Browser

Firefox 98

Client operating system

macOS

Server operating system

Linux 5.4.0-100-generic x86_64

Web server

No response

Database engine version

No response

PHP engine version

No response

Nextcloud version

23.0.2

Updated from an older installed version or fresh install

Fresh install

List of activated apps

No response

Nextcloud configuration

No response

Web server error log

No response

Log file

No response

Browser log

No response

Additional info

No response

@paradeiser paradeiser added 0. to triage Pending approval or rejection bug labels Mar 11, 2022
@paradeiser
Copy link
Author

I wonder why this issue doesn't even get tagged / assigned, tho it corrupts calendar-data.

Am I missing something? 🧐

@ChristophWurst
Copy link
Member

what do you expect?

@paradeiser
Copy link
Author

I hoped for something like:
"Thanks, we could reproduce this behavior and this is indeed a bug.
We tag it as "1. to develop / fix" (with high priority, as it corrupts user-data)."

What could I expect?

Danke Christoph!

@ChristophWurst
Copy link
Member

Fair enough. We don't have the resources to reproduce every single report at the moment.

@paradeiser
Copy link
Author

Still present in
Calendar app 3.3.1
Nextcloud 24.0.1

This bug makes it dangerous to check the "can edit" option, if a calendar is shared.

@raimund-schluessler
Copy link
Member

Related to #1587.

We had the same issue in Tasks, see nextcloud/tasks#862 and nextcloud/tasks#902. The solution was to treat tasks/events in shared calendars with an access class other than PUBLIC as read-only. Everything else doesn't make sense and leads to data loss for the owner of the calendar.

I think this should actually be implemented in server (server should refuse any change of events with access class other than PUBLIC in shared calendars not coming from the owner), but having it in Calendar is a good fix, I think.

@allout58
Copy link

I believe it's just a different way of hitting the same issue, but wanted to note that this also occurs if you have an event in a Shared Calendar with Edit enabled and set it's visibility to "When shared show only busy"

@Urmel
Copy link

Urmel commented Sep 21, 2023

I believe it's just a different way of hitting the same issue, but wanted to note that this also occurs if you have an event in a Shared Calendar with Edit enabled and set it's visibility to "When shared show only busy"

Hi !

This issue was also discussed in nextcloud/server#5551

I actually have this situation at the moment: we have a group calendar in which we keep events for the group (everyone has edit rights). My first intuition was that when I create an event and set it to "when shared show only as busy" that it would still be edit/readable by the other group members, but would be shown to people only having view rights only as busy.

To create a private event that also is private, I would actually create it in my own calender (and maybe share that read-only to the group). That IMHO resembles the general approach also in Outlook (though that program has more fine-grained access control that just view vs. edit).

@Urmel
Copy link

Urmel commented Nov 7, 2023

Haven't found any specification so far, but the Davical project has something for them. It talks about how to handle private events (the spec implies that the calendar might be shared as it states "all except [...] user"): https://wiki.davical.org/index.php?title=Features

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. to triage Pending approval or rejection bug
Projects
None yet
Development

No branches or pull requests

5 participants