Keep unshared calendars in trashbin to enable restoring them for group shares

Steps to reproduce

Create a new calendar and a single event within
Share the calendar with a group
As a user within the group the calendar is shared with, go to the calendar edit menu, cancel the subscription
The calendar will be gone (forever)
As the initial user, stop sharing the calendar with the group
Re-share the calendar with the group
As the user who deleted the calendar, check if it reappeared. It won't have.

Expected behavior

When the user sharing the calendar is canceling the share and then re-shares it with the same group, every user in the group should see the calendar. Even (or especially) those who previously unsubscribed from it.
Alternatively, keep unsubscribed shared calendars in users trash bin forever, allowing them to restore as long as the calendar is still shared.

Actual behaviour

When I unsubscribe a calendar by accident and miss the short time-frame to cancel the delete operation, there is no chance for me to get the calendar back. It will effectively be gone forever until the user who shared the calendar with a group explicitly re-shares it with me/my user, nullifying all the advantages that come with "share with group".

Calendar app version

4.7.6

CalDAV-clients used

DAVx5, Gnome Integration

Browser

Firefox 126.0.2 64-Bit

Client operating system

Ubuntu 22.04 64-Bit

Server operating system

Debian 11

Web server

Apache

Database engine version

PostgreSQL

PHP engine version

PHP 8.1

Nextcloud version

29.0.1

Updated from an older installed version or fresh install

Updated from an older version

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

IIRC correctly from #43117 this use case should have been covered. Do you have access to your database? If so, can you observe the following four states of the table for the resource?

State 1: After Alice (the calendar owner) has shared the Calendar with the group
State 2: Bob (sharee) has removed the calendar from themselves
State 3: Alice has removed the group share
State 4: Alice has reshared the calendar with the group

IIRC correctly from #43117 this use case should have been covered. Do you have access to your database? If so, can you observe the following four states of the table for the resource?

State 1: After Alice (the calendar owner) has shared the Calendar with the group State 2: Bob (sharee) has removed the calendar from themselves State 3: Alice has removed the group share State 4: Alice has reshared the calendar with the group

Unfortunately I can't provide you with the database states out of the box. I'll ask our admin to perform the check/provide the requested info.

SELECT * FROM oc_dav_shares where type='calendar' AND resourceid=<your_resource_id>; is the query

Thanks for helping out with the query. Our admin didn't react to my request yet, so I ran it myself. I'd probably need a little bit more help though 😅

SELECT * FROM oc_dav_shares where type='calendar' AND resourceid=<your_resource_id>; is the query

Pardon this potentially stupid question, but how do I figure the appropriate resource id? I've ran the query without limiting myself to a certain resource id, which yielded just 41 results (way less than expected), so I was able to look at the whole table. Still I don't grasp what I'd see there besides the "access" column which seems to represent some sort of counter?

EDIT: Had some bad sleep last night, took me a while to grasp the concept of what I'm supposed to give you 🤦 Here you go:

State 1:

98 | principals/groups/operations          | calendar |      2 |        496 |

State 2:

98 | principals/groups/operations          | calendar |      2 |        496 | 
99 | principals/users/me                   | calendar |      5 |        496 |

State 3:

99 | principals/users/me                   | calendar |      5 |        496 |

State 4:

99 | principals/users/me                   | calendar |      5 |        496 | 
101 | principals/groups/operations         | calendar |      2 |        496 |

So it seems the removal of the share didn't clean the "stop sharing with me" :/ Is there anything else I can you provide with?

No that is exactly what I need actually, thanks for that.

The following issue:

User Alice shares a Calendar with resource id 1 with two groups.

Our state:

1 | principals/groups/groupA          | calendar |      1 |        123456 | 
2 | principals/groups/groupB          | calendar |      1 |        123456 |

Bob is a member of group A. He unshares the calendar from himself.

Our state:

1 | principals/groups/groupA          | calendar |      1 |        123456 | 
2 | principals/groups/groupB          | calendar |      1 |        123456 | 
3 | principals/users/bob                   | calendar |      5 |        123456 |

Then Alice unshares the Calendar from group B. Since the resource ID is identical for both shares, the only way we can differentiate the shares is by the principal, so we delete table row 2. For Bob, the sharing code doesn't know which group Bob is a member of, so it keeps his unshare for the resource.

Our state:

1 | principals/groups/groupA          | calendar |      1 |        123456 | 
3 | principals/users/bob                   | calendar |      5 |        123456 |

Since we don't want Bob to have his unshare removed when we unshare a calendar with Group B (which he is not a member of), the code works as intended.

When Alice reshares the calendar with Group B, the code still doesn't know if Bob is a member of that group, so it doesn't touch the unshare either.

If we switch out Bob's Group membership, i. e. he is part of Group B instead of Group A, we get the exact issue you're facing. But since we don't know Bob's Group membership, we can't do anything about it.

What Alice can do, is share the Calendar again directly with Bob, which is the only way we can restore that calendar without breaking other group (un)shares.

Unfortunately that is the current limitation of not expanding group memberships when managing shares.

Additionally, sharing a calendar with a user that is a member of both groups, for example is also an issue - what do we do in case Bob is a member of both group A and B, unshares the calendar, and Alice then unshares the calendar for one group but not the other? Do we keep his unshare entry or delete it?

I hope this makes sense, sorry I don't have better news!

I want to add that this bug is also in effect if a user is deleted and re-created with the same login name. The "unshare from me" stays in place, makes it hard to get users back into a resource without them having to re-do all of their sync setup.

This also seems to happen, when a calendar synchronized with an iphone is set to be hidden.
The user then has no way to reactivate the calendar in the web interface.
Would be nice to have the "un-un-sharing" feature.

The only workaround until this issue is fixed seems to be, to manually and directly share the un-shared calender with the user, that (maybe accidentally) un-shared the group share. That was only logistically solvable by heavy use of the impersonate app by the admin.
also gave
occ dav:remove-invalid-shares
a shot, but that didn't work out.

I wonder so few people actually complain about this. Are shared group calendars something this exotic, or may this simply not get noticed by people?

@MPStudyly

@MPStudyly Most of "my" users using nextcloud are not even aware of the possibility to write issues here. Which is fine.
Here is an example in the forum: https://help.nextcloud.com/t/calendar-how-to-undo-unshare-from-me/119922
This post has 346 views.

I wonder so few people actually complain about this. Are shared group calendars something this exotic, or may this simply not get noticed by people?

It has noticed, some years ago - but I simply worked around it. Every evening, I have a lot of automated tasks running to address issues, for this: DELETE FROM oc_dav_shares where type = 'calendar' AND access = 5;

@MPStudyly Most of "my" users using nextcloud are not even aware of the possibility to write issues here. Which is fine. Here is an example in the forum: https://help.nextcloud.com/t/calendar-how-to-undo-unshare-from-me/119922 This post has 346 views.

True, I didn't think of the forum as a place for plain (non techy/dev) users 🤦

It has noticed, some years ago - but I simply worked around it. Every evening, I have a lot of automated tasks running to address issues, for this: DELETE FROM oc_dav_shares where type = 'calendar' AND access = 5;

I see, so you basically eliminated the possibility to unshare calendars for all your users?

We ran into this problem as well when setting up the tasks app.

In our setup (NC 30.0.12), users share their personal calendars with all their team.
Some team member A tracks their tasks as part of this shared calendar.
All other team members B want to see the calendar, but not the tasks. Therefore, team members B "unshare" the tasks of A. Because of tasks being a part of the calendar, the calendar also vanishes. It might still be recoverable in the tasks app in the trash bin for 30 days, but the trash bin doesn't open in the front end either due to another bug.
The calendar app trash bin does not include the calendars unshared in the tasks app.
If A unshares for the group and reshares its calendar, this doesn't let the calendar reappear for team members B as described above.

There are workarounds like secondary calendars for personal tasks only, but we still need to get the calendars back.

Since we do not have database access (which is quite common for all hosted nextclouds I believe?), we cannot easily use the database commands listed above.

As far as I understand, #52046 should have solved this issue. Although we are on NC 30.0.12 it is still present though...

See the troubleshooting article: https://docs.nextcloud.com/server/30/admin_manual/groupware/troubleshooting.html.

In short: User A needs to share his calendar once with User B to correct the state.

Navigation Menu

Repository navigation

Keep unshared calendars in trashbin to enable restoring them for group shares #45783

Steps to reproduce

Expected behavior

Actual behaviour

Calendar app version

CalDAV-clients used

Browser

Client operating system

Server operating system

Web server

Database engine version

PHP engine version

Nextcloud version

Updated from an older installed version or fresh install

List of activated apps

Nextcloud configuration

Web server error log

Log file

Browser log

Additional info

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Keep unshared calendars in trashbin to enable restoring them for group shares #45783

Description

Steps to reproduce

Expected behavior

Actual behaviour

Calendar app version

CalDAV-clients used

Browser

Client operating system

Server operating system

Web server

Database engine version

PHP engine version

Nextcloud version

Updated from an older installed version or fresh install

List of activated apps

Nextcloud configuration

Web server error log

Log file

Browser log

Additional info

Activity

miaulalala commented on Jun 11, 2024

MPStudyly commented on Jun 11, 2024

miaulalala commented on Jun 13, 2024

MPStudyly commented on Jun 17, 2024

miaulalala commented on Jun 17, 2024

miaulalala commented on Jun 17, 2024

12 remaining items

despens commented on Dec 8, 2024

b3nks commented on Mar 31, 2025

b3nks commented on Apr 1, 2025

MPStudyly commented on Apr 1, 2025

b3nks commented on Apr 1, 2025

AmatorPhasma commented on Apr 1, 2025

MPStudyly commented on Apr 2, 2025

fossil-free commented on Jul 3, 2025

kesselb commented on Jul 3, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions