Mail invitation - There was an error updating your attendance status.

[netaviator]

Steps to reproduce

1. Create an appointment
2. Add attendee to meeting -> mail is created
3. Click accept button in mail

Expected behaviour

Status of attendee should be updated in the calendar view.

Actual behaviour

The following error is shown: There was an error updating your attendance status. Please contact the organizer directly.

Already tried

I already found this post with the same problem and tried to use another mail address for my Nextcloud account without success. There is currently no user sharing the exact same mail address. https://help.nextcloud.com/t/solved-cannot-accept-calendar-invitation/50154

Server configuration

Operating system: Ubuntu 16.04 Web server: Apache Database: MySQL PHP version: 7.2.12 Server version: (see your admin page) 15.0.7 Calendar version: (see the apps page) 1.6.5 Updated from an older installed version or fresh install: Yes, updated since ownCloud 8 Signing status (ownCloud/Nextcloud 9.0 and above):

No errors have been found.

List of activated apps:

Enabled:
- accessibility: 1.1.0
- activity: 2.8.2
- admin_audit: 1.5.0
- bruteforcesettings: 1.3.0
- calendar: 1.6.5
- cloud_federation_api: 0.1.0
- contacts: 3.1.1
- data_request: 1.2.0
- dav: 1.8.1
- deck: 0.6.1
- federatedfilesharing: 1.5.0
- federation: 1.5.0
- files: 1.10.0
- files_markdown: 2.0.6
- files_pdfviewer: 1.4.0
- files_sharing: 1.7.0
- files_texteditor: 2.7.0
- files_trashbin: 1.5.0
- files_versions: 1.8.0
- files_videoplayer: 1.4.0
- gallery: 18.2.0
- groupfolders: 3.0.0
- lookup_server_connector: 1.3.0
- notifications: 2.3.0
- oauth2: 1.3.0
- password_policy: 1.5.0
- provisioning_api: 1.5.0
- quota_warning: 1.4.0
- sharebymail: 1.5.0
- tasks: 0.9.8
- theming: 1.6.0
- twofactor_backupcodes: 1.4.1
- twofactor_totp: 2.1.2
- twofactor_u2f: 2.1.3
- updatenotification: 1.5.0
- workflowengine: 1.5.0
Disabled:
- comments
- encryption
- files_external
- files_retention
- firstrunwizard
- logreader
- nextcloud_announcements
- serverinfo
- support
- survey_client
- systemtags
- user_ldap

Nextcloud configuration:

{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"cloud.xxxxxxx.xxxxxxx"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"overwrite.cli.url": "https:\/\/cloud.xxxxxxx.xxxxxxx",
"dbtype": "mysql",
"version": "15.0.7.0",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"logtimezone": "UTC",
"installed": true,
"maintenance": false,
"loglevel": 2,
"theme": "",
"trashbin_retention_obligation": "auto, 14",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "sendmail",
"mail_smtpauthtype": "LOGIN",
"updater.release.channel": "stable"
}
}

Are you using external storage, if yes which one: local/smb/sftp/... no

Are you using encryption: yes/no no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... no

Client configuration

Browser: Firefox , Chrome

Operating system: Windows 10, macOSX, iOS

CalDAV-clients: iOS

Logs

Web server error log

Nothing

Log file (data/nextcloud.log)

Nothing

Browser log

Nothing

[Beheadedstraw]

https://help.nextcloud.com/t/calendar-sharing-nextcloud-15/48664/5

On Wed, Sep 14, 2022 at 12:43 PM Anton Oellerer @.***> wrote:

Do you mean in the admin settings or in the app user settings? Or in each specific calendar setting?

— Reply to this email directly, view it on GitHub https://github.com/nextcloud/server/issues/15814#issuecomment-1247102340, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNNBZ43XLD66NK7CZ4MRCLV6IFFRANCNFSM4HRDVYWQ . You are receiving this because you commented.Message ID: @.***>

-- Devin Arendt Cell: 815-751-7723

[AntonOellerer]

I have similar settings as the user asking the questions, not restricting sharing to groups only

[ImaCrea]

Maybe you have some news about this issue @ChristophWurst please?

[jc97]

I think the priority for fixing this bug should be increased: It makes a quite essential function of a groupware (inviting people to events/meetings) partly unusable. And as mentioned, it produces a bad image for external users, who are not working with NextCloud yet. Several times I already got a reaction like "You and your not working 'special' open-source things. Just use normal software like Outlook".

Why is it so difficult to fix this bug? Maybe the community can help?

[ChristophWurst]

Community can help of course. As a starter we need to narrow down what triggers this error.

Does anyone have clean reproduction steps for this? I have never seen it myself and following the report and the comments it doesn't look like we know what conditions it needs to show.

[jc97]

As far as I remember it is an authentication error (at least when I have analyzed it the last time). Later, I can try to reproduce in a fresh NextCloud Installation and check which configuration produces it and check the error log. Maybe somebody else can do it too.

[ChristophWurst]

For a vanilla Nextcloud I can recommend spinning up an instance with https://hub.docker.com/_/nextcloud

Thanks!

[AntonOellerer]

I think it might help to log iTipMessage->scheduleStatus if https://github.com/nextcloud/server/blob/8b742ab39401ac4e4a40aa3aab01742ea09b8344/apps/dav/lib/Controller/InvitationResponseController.php#L85 returns with a status unequal to 1.2, then one might see what the reason for the error was

[ChristophWurst]

Moreover I would like to see the exported (and redacted) event ics that causes the error for external attendees

[AntonOellerer]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.4.1//EN
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
CREATED:20220914T174154Z
LAST-MODIFIED:20220914T174208Z
SEQUENCE:2
UID:a6ba401f-d6c4-4e5d-8fef-95e50920a31d
DTSTART;VALUE=DATE:20220927
DTEND;VALUE=DATE:20220928
STATUS:CONFIRMED
SUMMARY:Test
ATTENDEE;CN=user1@protonmail.com;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTIO
 N;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:user1@protonmail.com
ORGANIZER;CN=user2:mailto:user2@protonmail.com
DTSTAMP:20220914T174208Z
END:VEVENT
END:VCALENDAR

[miaulalala]

I saw comments that the error appears when users emails have special chacters in them.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.4.1//EN
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
CREATED:20220914T174154Z
LAST-MODIFIED:20220914T174208Z
SEQUENCE:2
UID:a6ba401f-d6c4-4e5d-8fef-95e50920a31d
DTSTART;VALUE=DATE:20220927
DTEND;VALUE=DATE:20220928
STATUS:CONFIRMED
SUMMARY:Test
ATTENDEE;CN=user1@protonmail.com;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTIO
 N;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:user1@protonmail.com
ORGANIZER;CN=user2:mailto:user2@protonmail.com
DTSTAMP:20220914T174208Z
END:VEVENT
END:VCALENDAR

Could you please let me know if the email addresses had any "+" sign in them before you redacted them?

cc @kesselb

[AntonOellerer]

No, just [a-z] characters

El vie, 28 oct, 2022 a las 10:11, Anna @.***> escribió:

I saw comments that the error appears when users emails have special chacters in them.

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 4.4.1//EN CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT CREATED:20220914T174154Z LAST-MODIFIED:20220914T174208Z SEQUENCE:2 UID:a6ba401f-d6c4-4e5d-8fef-95e50920a31d DTSTART;VALUE=DATE:20220927 DTEND;VALUE=DATE:20220928 STATUS:CONFIRMED SUMMARY:Test @.;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTIO @. @.*** DTSTAMP:20220914T174208Z END:VEVENT END:VCALENDAR

Could you please let me know if the email addresses had any "+" sign in them before you redacted them?

cc @.***(https://github.com/kesselb)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[miaulalala]

are you able to add some code to your nextcloud instance?

You could add the following to your \OCA\DAV\CalDAV\Schedule\Plugin::scheduleLocalDelivery method:

    // We only care when the message was successfully delivered locally
        if ($iTipMessage->scheduleStatus !== '1.2;Message delivered locally') {
            \OC::$server->get(\Psr\Log\LoggerInterface::class)->debug($iTipMessage->scheduleStatus);
            return;
        }

This would log any unsuccessful attempt to update the scheduling information on the event.

[AntonOellerer]

I have nextcloud installed via the snap package (which mounts the code as read-only), so it would take some fiddling around, but I will take a look on whether I can do it without too many complications

[AntonOellerer]

I followed this suggestion. There is no log output on invitation acceptance, but when sending the invite, the following message is logged:

Debug    no app in context  3.7;Could not find principal.

which seems to occur here:

https://github.com/sabre-io/dav/blob/9c04ba81fbdc70c314ef1cfcd1c890f540138016/lib/CalDAV/Schedule/Plugin.php#L419

[AntonOellerer]

It seems as if the previous comment about a user tracking the issue further down was deleted, but for me the suggested solution actually fixed the problem, thank you very much!

The issue for me was that I had two users (the root user and the personal user) both using my mail address (user2@protonmail.com in the example above), thus https://github.com/nextcloud/server/blob/master/apps/dav/lib/Connector/Sabre/Principal.php#L488 returned null.

[miaulalala]

Since we can't really force unique email addresses, I wonder how we could best handle this.

One To Do is definitely logging more of the Scheduling code so we get a better idea where things are going wrong, but other than that, if the principal can't be identified, there is nothing easy we can do to mitigate this.

In principle, it should be possible to use a different search parameter on getPrincipalByUri

 /**
     * Finds a principal by its URI.
     *
     * This method may receive any type of uri, but mailto: addresses will be
     * the most common.

We could try to pass a user ID wherever possible. For the InvitationResponseController for example, it should be possible to encode the sender user ID in the InivitationResponse Token, or pass it via URI.

\OCA\DAV\Connector\Sabre\Principal::searchPrincipals allows the prefix path to be set to 'principals/users' for example:

    /**
     * @param string $prefixPath
     * @param array $searchProperties
     * @param string $test
     * @return array
     */
    public function searchPrincipals($prefixPath, array $searchProperties, $test = 'allof') {
        if (count($searchProperties) === 0) {
            return [];
        }

        switch ($prefixPath) {
            case 'principals/users':
                return $this->searchUserPrincipals($searchProperties, $test);

            default:
                return [];
        }
    }

\Sabre\DAVACL\PrincipalBackend\AbstractBackend::findByUrion the other hand only allows mailto: params. So there might be a lot of very careful extending to do.

@tcitworld I would apprechiate your input on this idea (searching via case 'principals/users':)

[tcitworld]

Since we can't really force unique email addresses, I wonder how we could best handle this.

I think we should keep working with email addresses only. In the above case - which is quite specific - we could just use the first user found if there's multiple, instead of returning null if there's more than one.

I'm open to other solutions if the actual issues from other people here are different (special characters in emails?), but I don't think it's worth thinking further otherwise.

[francescor]

Hi, this is still painful

as for what is written above:

Do all Nextcloud users have unique email addresses?

=> If no, that’s not supported

It is not clear to us what that users stands for

We see emails are stored in the oc_accounts DB table: and, as afaik that table includes nextcloud users, the one I see in https://nextcloud-URL/settings/user am I right? so, in our setup all email cited in that url all are unique, while many records oc_accounts DB table shows the same email address.

So, does the about unique email addresses requirement means: uniqueness of emails in the oc_accounts DB table?

[RodSeq]

The bug is still present in newest Nextcloud 25.0.2 / Calendar 4.2.1, making impossible to use Nextcloud for meeting invitations to external contacts (that are not users of Nextcloud).

Below is a very simple way to reproduce the bug:

• Create a meeting in Calendar, adding as attendee an external email contact (not user of Nextcloud).
• Open the Nextcloud email invitation then click "Accept": a message error is displayed "There was an error updating your attendance status. Please contact the organizer directly." - see screenshot below.

[miaulalala]

The bug is still present in newest Nextcloud 25.0.2 / Calendar 4.2.1, making impossible to use Nextcloud for meeting invitations to external contacts (that are not users of Nextcloud).

Below is a very simple way to reproduce the bug:

• Create a meeting in Calendar, adding as attendee an external email contact (not user of Nextcloud).
• Open the Nextcloud email invitation then click "Accept": a message error is displayed "There was an error updating your attendance status. Please contact the organizer directly." - see screenshot below.

Please share your logs and your email address if you can. I have tried the invitations with an external email address and it works for me.

[RodSeq]

@miaulalala the external email address I used is "treewallet@posteo.net". I have no error message in the log. Please note that you need to "Accept" and open the meeting invitation link in a browser where you are not logged in Nextcloud in order to trigger the bug mentioned above (still present in NC 25.0.3).

[SergeyMosin]

In order for (external) users to accept invitations at least two settings must be enabled in Settings > Administration > Sharing:

1. Allow apps to use the Share API
2. Allow sharing with groups

This is very confusing, plus I might not want to Allow sharing with groups but still want external users accept invitations.

Call trace:

The accept function here: https://github.com/nextcloud/server/blob/aaf759bbb09e695de63fafe09405fe71dc6cc3bb/apps/dav/lib/Controller/InvitationResponseController.php#L78-L85

Will end-up in the findByUri function here: https://github.com/nextcloud/server/blob/aaf759bbb09e695de63fafe09405fe71dc6cc3bb/apps/dav/lib/DAV/GroupPrincipalBackend.php#L273-L278

Which will do this check: https://github.com/nextcloud/server/blob/aaf759bbb09e695de63fafe09405fe71dc6cc3bb/apps/dav/lib/DAV/GroupPrincipalBackend.php#L345-L347

---

Once again, very confusing setting for the end user.

[datenchef]

Thanks, @SergeyMosin - i directly looked up our settings because its a urgent topic to send invitations to external users. We do have both settings checked but have this error screen like @RodSeq...

Becomes more absurd...

[patzm]

I am on NextCloud 25.0.2, when I go to Personal settings ➡️ Groupware (there is no Availability), then the following pop-up appears:

My menu:

[miaulalala]

I am on NextCloud 25.0.2, when I go to Personal settings arrow_right Groupware (there is no Availability), then the following pop-up appears:

My menu:

I think this is a different issue. Can you please take a look at your logs and see what it says?

[SergeyMosin]

@datenchef In my case the error code( 3.7 ) was thrown here: https://github.com/nextcloud/3rdparty/blob/299e51ccbb82251452de18d52a9b4b7e8207eb82/sabre/dav/lib/CalDAV/Schedule/Plugin.php#L417-L422

but there are other error codes ( $iTipMessage->scheduleStatus ) that can cause this problem like 5.2 or 3.8, etc... here for example: https://github.com/nextcloud/3rdparty/blob/299e51ccbb82251452de18d52a9b4b7e8207eb82/sabre/dav/lib/CalDAV/Schedule/Plugin.php#L444-L477

You can check the error code by following suggestion here: https://github.com/nextcloud/server/issues/15814#issuecomment-1294703214

[patzm]

I couldn't find a log entry on the server with an error or warning, also no INFO event. Maybe it is client (Browser) side? How to check that?

[miaulalala]

You can open a console for your browser (Chrome is rightclick -> inspect and then either console or network tab), and firefox should work the same. Errors in the Javascript console or network tabs are marked in red.

I couldn't find a log entry on the server with an error or warning, also no INFO event. Maybe it is client (Browser) side? How to check that?

[patzm]

could not load existing availability Error: invalid BYDAY value "-1SU&#13"
    BYDAY index.esm.js:11892
    _stringToData index.esm.js:11969
    fromICAL index.esm.js:6043
    _parseValue index.esm.js:7241
    _handleContentLine index.esm.js:7215
    i index.esm.js:6994
    _eachLine index.esm.js:7484
    i index.esm.js:6993
    x index.esm.js:14610
    n CalendarService.js:72
    u runtime.js:288
    _invoke runtime.js:262
    C runtime.js:83
    w logger.js:26
    i logger.js:26
    promise callback*w logger.js:26
    i logger.js:26
    promise callback*w logger.js:26
    i logger.js:26
    k logger.js:26
    k logger.js:26
    S CalendarService.js:48
    O CalendarService.js:48
    e Availability.vue:85
    u runtime.js:288
    _invoke runtime.js:262
    C runtime.js:83
    Y PreferenceService.js:43
    i PreferenceService.js:43
    H PreferenceService.js:43
    H PreferenceService.js:43
    mounted Availability.vue:83
    VueJS 4
    44435 settings-personal-availability.js:9
    Webpack 5
Availability.vue:98

and directly after that:

The fact that the original error relates to BYDAY, I suppose some birthday in one of my contacts is mal-formatted. Would be sad though if this breaks something in settings. If I assume correctly that BYDAY referres to birthday, then I would open another issue. If so, please feel free to hide my comments above and this one.

[tcitworld]

Nope, it's a rule to express days of the week for the availability setting. Somehow a value seems to have got HTML entity encoded.

[miaulalala]

No I think your VAVAILABILITY may malformed, not any of your contacts.

Can you please open your network tab in the broswer console and look at the response?

Also, please open another ticket with the error logs your found so we can keep the issues separate.

[miaulalala]

@datenchef In my case the error code( 3.7 ) was thrown here: https://github.com/nextcloud/3rdparty/blob/299e51ccbb82251452de18d52a9b4b7e8207eb82/sabre/dav/lib/CalDAV/Schedule/Plugin.php#L417-L422

but there are other error codes ( $iTipMessage->scheduleStatus ) that can cause this problem like 5.2 or 3.8, etc... here for example: https://github.com/nextcloud/3rdparty/blob/299e51ccbb82251452de18d52a9b4b7e8207eb82/sabre/dav/lib/CalDAV/Schedule/Plugin.php#L444-L477

You can check the error code by following suggestion here: #15814 (comment)

I think the findByUri method is indeed the culprit here.

@tcitworld @ChristophWurst what do you think - document this behaviour or see to it that we provide our own CalendarPrincipalBackend for it? We do have an AbstractPrincipalBackend for the resources already, so it should be possibe.

[patzm]

☝️ Issue #36245 opened, let's continue the discussion over there. ~And again, admins feel free to hide my comments (they are quite long).~ Update: I was able to hide them.

[nderambure]

Hello, just to subscribe to this bug, I'm having same problem with NC 25.0.3 on Debian 11 / Apache / MariaDB.

It happens in one case : On my NC instance I have a few groups, that don't see each others. I'm in my work group and in admin group. If someone from another group adds me as participant with my email used for my NC account, the click on accept link received by mail throws me the error, even if I'm already logged in.

In other hand, this works perfectly in my own group.

Also, the "Restrict users to only share..." checkbox is no more present in Admin settings > Share. Now I have a hardly understandable (for a french guy) checkbox called "Guests will still be able to see accounts from any group they are added to" which is by the way not translated in french.

I've seen that you assigned yourself this bug @miaulalala so I suppose you work on this :)

[Der-K-2000]

I can confirm this annoying bug, which makes it very difficult on a professional level. I already mentioned it here, but it was a different issue. I'm glad, I could find the right topic. Hopefully there will be a fix soon (even though the initial post 4 years ago).

[Beheadedstraw]

The main problem here that I'm seeing is restricting this particular function to the Share API. I get that this is groupware, but email isn't, not to mention restricting email should be done on the SMTP/Exchange server, otherwise you're just introducing more headache to sysadmins everywhere.

[Der-K-2000]

In order for (external) users to accept invitations at least two settings must be enabled in Settings > Administration > Sharing:

1. Allow apps to use the Share API
2. Allow sharing with groups

Trail and error: Those two options didn't change anything in my case, BUT I unchecked the option onlyShareWithGroupMembers (which was active) and now it works and guests can accept/deny invitations by the link in the e-mail (→ /apps/dav/invitation/accept/ and /deny).

[RodSeq]

@SebastianBerlin unchecking the option onlyShareWithGroupMembers is not an option: this creates a Privacy issue with private groups that should not see the users from other groups.

[Der-K-2000]

@SebastianBerlin unchecking the option onlyShareWithGroupMembers is not an option: this creates a Privacy issue with private groups that should not see the users from other groups.

I know. In my case neglectable, because there is only one group.

It was just a hint for the involved devs, that this could solve the issue.

[Der-K-2000]

Trail and error: Those two options didn't change anything in my case, BUT I unchecked the option onlyShareWithGroupMembers (which was active) and now it works and guests can accept/deny invitations by the link in the e-mail (→ /apps/dav/invitation/accept/ and /deny).

Weird, since NC 26 (stable) it's not possible anymore with this dirty solution.

Guests receive this awful message after they clicked 'accept' in the mail they got.

That is really really bad, especially for professionals.

[ChristophWurst]

I think the findByUri method is indeed the culprit here.

@tcitworld @ChristophWurst what do you think - document this behaviour or see to it that we provide our own CalendarPrincipalBackend for it? We do have an AbstractPrincipalBackend for the resources already, so it should be possibe.

After reading the ticket details and responses like https://github.com/nextcloud/server/issues/15814#issuecomment-1396466844 it sounds like documentation could be a goof first step, and so is adding more logging.

I'm not acquainted with the internals of Sabre and can't tell if writing our own principal backend is a good idea.

[ChristophWurst]

If I'm not mistaken we are talking about two problems in this tickets

1) How to deal with non-unique email addresses and mapping them to principals 2) Sharing settings restricting principals during search

[ChristophWurst]

Ran into this while testing an unrelated bug on my dev env: Message not delivered locally with status: 3.7;Could not find principal. (level=0)

Edit: same email address assigned to three test users.

[matwacim]

I still have the initially described problem on NC 25. Actually the calender is unusable if you want to send meetings to other participants. All workarounds with checking/unchecking the mentioned share checkboxes didnt help. this is a problem since 2019. is it something that is happing for only some installation or is it a general problem? If it is, shouldn't this get a higher prio? however I a still happy for all NC offers for free, but regarding collaboration this would really be important.

[miaulalala]

I still have the initially described problem on NC 25. Actually the calender is unusable if you want to send meetings to other participants. All workarounds with checking/unchecking the mentioned share checkboxes didnt help. this is a problem since 2019. is it something that is happing for only some installation or is it a general problem? If it is, shouldn't this get a higher prio? however I a still happy for all NC offers for free, but regarding collaboration this would really be important.

I get that it's frustrating, but here's the issue. We can't really deny user accounts from using email addresses that have already been used by someone else. But that leads to errors in Sabre since the calendaring system assumes the email is a unique identifier. So it finds multiple calendars for the same email address for different user accounts, but since there is nothing telling the code which one is the right one, the code, instead of leaking info, stops processing the data and errors out.

There is currently no good way forward to solve this issue. Either we change stuff in Sabre in a way that doesn't adhere to the calendaring RFCs, leading to unforseen bugs and possibly even compatibility issues with other calendaring clients. Or we adjust Nextcloud to disallow duplicate emails, which will have wide reaching effects on all parts of NC. Both of those are not something we can simply fix. Any change for this needs to have as few side effects as possible, ensure we still adhere to the calendaring RFCs and also not change the core of how NC works.

[RodSeq]

I still have the initially described problem on NC 25. Actually the calender is unusable if you want to send meetings to other participants. All workarounds with checking/unchecking the mentioned share checkboxes didnt help. this is a problem since 2019. is it something that is happing for only some installation or is it a general problem? If it is, shouldn't this get a higher prio? however I a still happy for all NC offers for free, but regarding collaboration this would really be important.

I get that it's frustrating, but here's the issue. We can't really deny user accounts from using email addresses that have already been used by someone else. But that leads to errors in Sabre since the calendaring system assumes the email is a unique identifier. So it finds multiple calendars for the same email address for different user accounts, but since there is nothing telling the code which one is the right one, the code, instead of leaking info, stops processing the data and errors out.

There is currently no good way forward to solve this issue. Either we change stuff in Sabre in a way that doesn't adhere to the calendaring RFCs, leading to unforseen bugs and possibly even compatibility issues with other calendaring clients. Or we adjust Nextcloud to disallow duplicate emails, which will have wide reaching effects on all parts of NC. Both of those are not something we can simply fix. Any change for this needs to have as few side effects as possible, ensure we still adhere to the calendaring RFCs and also not change the core of how NC works.

This bug main problem is not with duplicated emails: main problem is that any user not having a Nextcloud account can't accept or deny any meeting invitation sent through Nextcloud Calendar App. This repressents a very basic feature that is not working today on Nextcloud: should be fix as soon as possible, duplicated emails problem can be fixed later on.

[lars-becker]

@miaulalala:

There is currently no good way forward to solve this issue. Either we change stuff in Sabre in a way that doesn't adhere to the calendaring RFCs, leading to unforseen bugs and possibly even compatibility issues with other calendaring clients. Or we adjust Nextcloud to disallow duplicate emails, which will have wide reaching effects on all parts of NC. Both of those are not something we can simply fix. Any change for this needs to have as few side effects as possible, ensure we still adhere to the calendaring RFCs and also not change the core of how NC works.

Would a be possible to add a warning in the admin interface or via occ command that shows which accounts are affected? Part of the problem is that most affected users aren't aware of the issue and don't have a clue how to work around it. The result is that Nextcloud generates errors and seems unreliable to our own users and others.

[Beheadedstraw]

The easiest way to fix this right now is to just not allow invitations to anyone outside of Nextcloud. Check if the email is registered, if it's not then throw an error saying so. Another thing is to just not allow duplicate emails for different users, this seems like a security problem anyways allowing multiple users to have the same email.

On Tue, Jun 27, 2023 at 12:23 PM Lars Becker @.***> wrote:

@miaulalala https://github.com/miaulalala:

There is currently no good way forward to solve this issue. Either we change stuff in Sabre in a way that doesn't adhere to the calendaring RFCs, leading to unforseen bugs and possibly even compatibility issues with other calendaring clients. Or we adjust Nextcloud to disallow duplicate emails, which will have wide reaching effects on all parts of NC. Both of those are not something we can simply fix. Any change for this needs to have as few side effects as possible, ensure we still adhere to the calendaring RFCs and also not change the core of how NC works.

Would a be possible to add a warning in the admin interface or via occ command that shows which accounts are affected? Part of the problem is that most affected users aren't aware of the issue and don't have a clue how to work around it. The result is that Nextcloud generates errors and seems unreliable to our own users and others.

— Reply to this email directly, view it on GitHub https://github.com/nextcloud/server/issues/15814#issuecomment-1609936217, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNNBZ6DF6Q3B37G2GJO4YDXNMJJFANCNFSM4HRDVYWQ . You are receiving this because you commented.Message ID: @.***>

-- Devin Arendt Cell: 815-751-7723

[RuStrannik]

The easiest way to fix this right now is to just not allow invitations to anyone outside of Nextcloud.

Oh, then I know how to fix all bugs and solve all problems in any software: just avoid using it! Problems?

Now seriously: no, this is not a fix, this is crippling. Ability to send email invitations to non-registered users and processing feedback from them is essential part of functionality and it has to be fixed properly.