Users A and B have shared there CalDAV/Nextcloud calendars to each other. So that they can see/RO each others personal calendar. The calendars were shared through the Nextcloud web UI and show up nicely in each others calendar panel.
When users A and B now get an event invitation from an external sender and both accept the invitation, the confirmation email from each is send to the external inviter (ok) but for user A EMC tries to save the event to the shared RO calendar of user B throwing an error as this calendar is RO for user A.
In all account settings the own personal Nextcloud calendars are set as default folders. Expectation would be that EMC would try to save the event in the set default folder/personal calendar and not in a shared RO calendar.
This is a kind of mission critical bug, I’m afraid.
We’re currently evaluating eM Client as a (last chance non-Outlook) alternative to Thunderbird (which is just unbearable slow when interacting with calendars) as a client to our Nextcloud.
And we’re experiencing the exact same behavior that iljur describes.
Several users have (r/o) access to one another’s calendars
Any invite (internal or external) to more than one of those users will break things
As soon as eM client just sees an event that “fits” to an invite in any attached (shared) calendar, it will get kind of stuck to that calendar when it comes to interacting with the invite and completely ignores the default calendar set for the respective mail account, which should soley be used to interact with the invite.
We were so hopeful to be able to avoid Outlook (and the rest that comes with it) as everything else works so smoothly with eM Client, but this bug is actually a show stopper, that we can’t work around either.
So the question is: Is this bug already being worked on?
I had a long chat with the Support Team since I posted this issue and sent screenshots and screen recordings to show them the setup because they said that they could not reproduce it. Not sure if they really tried… Later they sent me some Beta versions. But that did not solve the problem. They only changed/simplified the error message and made it less meaningful (?!). It seemed kind of tough to convince them that this is really an annoying bug.
And today (!) I got the feedback that they forwarded the issue to the devs… Finally!!!
And yes, I agree that this bug could prevent someone to switch to eMC.
I must admit that this bug is somewhat related to Nextcloud. With Sogo calendar accounts the behaviour is different/as expected. Events are saved only to the personal calendar of the user, no attempt to “update” existing events in a shared RO calendar.
This is why we are thinking about switching to Sogo as our calendar/contacts server. Seems to be the more solid implementation and we already use it anyway for webmail service. Nextcloud is unfortunately more and more pain in the arm… but that is another story.
The problem is caused, that we are trying to find the event in all calendars and work with it in that folder. This is to support use cases for users with multiple calendar folders. So the problem is that we’ll find the event in read only shared calendar. What we will do now, that we will skip such read only folders from that lookup. The fix should be included in the next update.
I’m just afraid skipping read-only folders only won’t be enough to solve this, even though it might well be enough in our case.
If users A and B have access to eachother’s calendars, and then A invites B, the event can be seen by B’s eM Client as soon as A has created the event and B has synchronized A’s calendar.
It doesn’t really matter if A’s (shared) calender is read-only for B. Even if it’s writable, B should not interact with this event in A’s calendar, but with calendar configured for the mail account holding the invite.
At least, eM Client should skip all calendars not owned by the user when handling invites.
This should fix the problem in our case as well. Thanks a lot eMClient Team!
And I agree with @ncuser that all calendars should be skipped which are not owned by the user. Because most of the times you simply would want the event to be saved to your own calendar than to update an existing one in another user’s calendar. Even if it is writable.
The case where a user has several calendars and gets invited to an event several times and therefore an existing event needs to be updated sounds quite unusual to me at least.
It all boils down to give the user the choice where to look for, save or update an event. Automatic look up /saving seems not to be the best solution here. Though it sounds convenient of course in first sight, every day work too often prooved it is not. A choice would be good.