Incorrect number of participants when using contact groups

[ndo84bw]

Steps to reproduce

1. Create two empty contact groups named "Name1x" and "Name2x"
2. Create a contact named "Name 99 name99@example.com" and assign it to both contact groups
3. Create an appointment named "Test 1" with both contact groups "Name1x" and "Name2x" - Save
4. Create an appointment named "Test 2" with the contact group "Name1x" and Save
5. Edit the “Test 2” appointment and add the contact group "Name2x" and save again

Expected behavior

Test 1
Amount of Attendees = 2 (Organisator + Name99)

Test 2
Amount of Attendees = 2 (Organisator + Name99)

Actual behavior

Test 1
Amount of Attendees = 4 (Organisator + Name1x@group + Name2x@group + Name99)

ICS - Test 1 (both at once)

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//IDN nextcloud.com//Calendar app 6.5.0-dev.0//EN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20260616T101615Z
DTSTAMP:20260616T101939Z
LAST-MODIFIED:20260616T101939Z
SEQUENCE:4
UID:7bf93ca0-d727-4a4e-9b68-bd65ed683e64
DTSTART;TZID=Europe/Berlin:20260621T090000
DTEND;TZID=Europe/Berlin:20260621T093000
TRANSP:OPAQUE
STATUS:CONFIRMED
SUMMARY:Test 1 - both at once
DESCRIPTION:Two contact groups with the same contact were added with a sing
 le save
ATTENDEE;CN=Name1x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
 RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name1x@group
ATTENDEE;CN=Name2x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
 RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name2x@group
ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT;RSVP=TRUE;MEMBER="mailto:Name2x@group","mailto:Name1x@group";SCHEDULE
 -STATUS=1.1:mailto:name99@example.com
ORGANIZER;CN=admin:mailto:admin@example.net
END:VEVENT
END:VCALENDAR

Test 2
Amount of Attendees = 5 (Organisator + Name1x@group + Name99 + Name2x@group + Name99)

ICS - Test 2 (one at a time)

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//IDN nextcloud.com//Calendar app 6.5.0-dev.0//EN
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20260616T101809Z
DTSTAMP:20260616T102012Z
LAST-MODIFIED:20260616T102012Z
SEQUENCE:4
UID:994ea3c7-724b-4fef-b2f0-503343378b27
DTSTART;TZID=Europe/Berlin:20260621T110000
DTEND;TZID=Europe/Berlin:20260621T113000
TRANSP:OPAQUE
STATUS:CONFIRMED
SUMMARY:Test 2 - One at a time
DESCRIPTION:Two contact groups with the same contact were added one after t
 he other
ATTENDEE;CN=Name1x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
 RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name1x@group
ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT;RSVP=TRUE;MEMBER="mailto:Name1x@group";SCHEDULE-STATUS=1.1:mailto:nam
 e99@example.com
ATTENDEE;CN=Name2x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
 RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name2x@group
ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT;RSVP=TRUE;MEMBER="mailto:Name2x@group":mailto:name99@example.com
ORGANIZER;CN=admin:mailto:admin@example.net
END:VEVENT
END:VCALENDAR

Calendar app version

6.5.0-dev

CalDAV-clients used

Browser

Chromium 151

Client operating system

Manjaro Linux

Server operating system

docker-dev

Web server

None

Database engine version

None

PHP engine version

None

Nextcloud version

35.0.0 dev

Updated from an older installed version or fresh install

None

List of activated apps

Enabled:
    - appstore: 2.0.0-dev.0
    - calendar: 6.5.0-dev.0
    - circles: 35.0.0-dev.0
    - cloud_federation_api: 2.0.0-dev.0
    - comments: 2.0.0-dev.0
    - contacts: 8.8.0-dev.0
    - contactsinteraction: 2.0.0-dev.0
    - dashboard: 8.0.0-dev.0
    - dav: 2.0.0-dev.0
    - federatedfilesharing: 2.0.0-dev.0
    - federation: 2.0.0-dev.0
    - files: 3.0.0-dev.0 
    - files_reminders: 2.0.0-dev.0
    - files_sharing: 2.0.0-dev.0
    - files_trashbin: 2.0.0-dev.0
    - files_versions: 2.0.0-dev.0
    - lookup_server_connector: 2.0.0-dev.0
    - oauth2: 2.0.0-dev.0
    - profile: 2.0.0-dev.0
    - provisioning_api: 2.0.0-dev.0
    - settings: 2.0.0-dev.0
    - sharebymail: 2.0.0-dev.0  
    - systemtags: 2.0.0-dev.0
    - theming: 3.0.0-dev.0
    - twofactor_backupcodes: 2.0.0-dev.0
    - updatenotification: 2.0.0-dev.0
    - user_status: 2.0.0-dev.0
    - weather_status: 2.0.0-dev.0
    - webhook_listeners: 2.0.0-dev.0
    - workflowengine: 3.0.0-dev.0

Nextcloud configuration

Web server error log

Log file

Browser log

Additional info

Point 1 - Dedupe Participants

The code for deduplication already exists. See Test 1

The comparison probably fails because the participants in Test 2 have a "mailto" prefix

Ref:

calendar/src/components/Editor/Invitees/InviteesList.vue

Line 395 in fcb7dda

if (attendee.uri === email) {

Point 2 - No duplicate emails

Because the iTip Broker adds participants to an array before sending out invitations, duplicate emails are prevented (tested on a different instance with NC32 and Calendar 6.4.2)

Ref.: https://github.com/nextcloud/3rdparty/blob/69b1534909f2abd81621d03e3660398743c38ae5/sabre/vobject/lib/ITip/Broker.php#L934

Point 3 - Duplicate Organizer = Attendee
When Thunderbird creates an event, it also adds the organizer as an attendee. So the result of an event with one organizer and one attendee is 3. The calendar counts this multiple times, regardless of the groups. This was noticed during testing and could be also addressed. (tested on a different instance with NC32 and Calendar 6.4.2)

Question: New Issue or same okay?

Point 4 - Group in Event/ICS File
According to RFC, it is sufficient for a participant to be assigned to groups via MEMBER. The group itself does not need to be listed as a participant with "CUTYPE=GROUP". This "group" participant is also displayed by CalDAV clients like Thunderbird.

I can create the PR for this, but before a solution is built, I think we need to decide whether to simply exclude the groups from the count or to omit the groups entirely. The frontend currently needs the groups to render the collapsed section. If the groups are removed, the logic must be adapted to the MEMBER attribute.

Ref.:

calendar/src/components/Editor/Invitees/InviteesList.vue

Line 186 in fcb7dda

if (attendee.attendeeProperty.userType === 'GROUP') {

My recommendation would be:

• The calendar continues to count CUTYPE=GROUP (if the event was created externally with a group via CalDAV client)
• The calendar no longer lists the groups as attendees in the event, but only the attendee as a MEMBER of one or multiple groups
• The frontend builds the expandable groups based on the MEMBER attribute of the attendee and no longer based on the attendees from CUTYPE=GROUP
• The frontend renders an attendee of CUTYPE=GROUP as an attendee

I hope to receive positive and constructive feedback

[SebastianKrupinski]

Hi @ndo84bw

Thanks for the report. I agree the counts are confusing.

I think best solution would be to list all the members in a single list, with a indicator (icon) that they are part of a group. That said there will also need to be controls to remove an entire group.

Lets see what the design team thinks.

@GVodyanov @nimishavijay @kra-mo

[nimishavijay]

The count is indeed wrong (also counted wrong when groups are added in general, I think? see screenshot)

I am not sure if we should show the indicator icon as like you said we would need a way to remove the entire group, plus the icon would be repeated for each member in the group. I think showing duplicated users is ok, maybe there we can indicate the fact that that they are a part of a different group, maybe in the subline where it says "invitation sent"

[ndo84bw]

I cannot picture what @SebastianKrupinski is proposing. In my opinion the UI should still look the same as it does now. NC contact lists / NC teams as a collapsible group. After a user adds a group, they expect to see it there. And that way we also keep the anchor to remove the "group".

TL;DR

the root is how the attendee list is assembled, the count is just a symptom

Frontend @nimishavijay

• Move the frontend group anchor from CUTYPE=GROUP to all MEMBER entries.
• Frontend NC own group display unchanged as before (collapse/expand, remove, and the same user appearing in multiple groups stays as is)
• Show and count remaining real groups (list-test@example.net) like any other individual
• No longer show old fake groups (@group) and optionally stop counting them, because they will not exist in new events anymore

feasible/acceptable?

Backend @SebastianKrupinski

• Stop writing fake groups with CUTYPE=GROUP and @group into the event going forward
• Fix the prefix check so the same ATTENDEE does not end up in the event more than once
• Adding circles is currently broken! (master and NC33)

feasible/acceptable?

An absurd amount of brain power for "just" a wrong count. 🙃

Point 4

The easiest fix would be to just skip ATTENDEE entries with CUTYPE=GROUP when counting. That would leave only the "wrong" duplicate users from Test 2. BUT this only catches fake groups that NC writes itself. So we should also think about what happens when a "real" group like list-test@example.net is in the event and an invitation actually goes out - unlike @group with SCHEDULE-STATUS=5.0. NC cannot do that today, but CalDAV clients can. Not counting those feels wrong.

My proposal above is to accept that trade-off and rebuild NC Calendar so it no longer uses ATTENDEE with CUTYPE=GROUP to identify NC contact list / NC team groupings in the event, but only the MEMBER attribute instead. That way the GROUP type ATTENDEE entries NC generates can be left out of the ICS entirely, and ATTENDEE entries can still be counted the same way as before - with CUTYPE INDIVIDUAL and GROUP.

My target would look like this:

For Test 1

- ATTENDEE;CN=Name1x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
-  RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name1x@group
- ATTENDEE;CN=Name2x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
-  RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name2x@group
ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
 PANT;RSVP=TRUE;MEMBER="mailto:Name2x@group","mailto:Name1x@group";SCHEDULE
 -STATUS=1.1:mailto:name99@example.com

For Test 2

- ATTENDEE;CN=Name1x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
-  RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name1x@group
- ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
-  PANT;RSVP=TRUE;MEMBER="mailto:Name1x@group";SCHEDULE-STATUS=1.1:mailto:nam
-  e99@example.com
- ATTENDEE;CN=Name2x;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;
-  RSVP=TRUE;SCHEDULE-STATUS=5.0:mailto:Name2x@group
- ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
-  PANT;RSVP=TRUE;MEMBER="mailto:Name2x@group":mailto:name99@example.com
+ ATTENDEE;CN=Name99;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICI
+  PANT;RSVP=TRUE;MEMBER="mailto:Name2x@group","mailto:Name1x@group";SCHEDULE
+  -STATUS=1.1:mailto:name99@example.com

Old events would still group users correctly with the new logic, because MEMBER has already been written on INDIVIDUAL ATTENDEE entries up to now.

If we show "real" ATTENDEE entries with CUTYPE=GROUP as plain ungrouped individuals in the future, old events would still show the groups from MEMBER as collapsible as before. The fake group with CUTYPE=GROUP and @group would be rendered again in the frontend on top of that. Those need to be hidden. If that falls into the same logic block, we can also optionally skip the old fake groups when counting - so the count would be fixed for old events too.

Removing the @group ATTENDEE entries does not change email delivery, because they are already marked as undeliverable with SCHEDULE-STATUS=5.0.

The group display name that previously came from ATTENDEE;CN=Name1x would then come from the mailto of the MEMBER - "mailto:Name1x@group".

For contact groups:

calendar/lib/Controller/ContactController.php

Line 241 in 1d94540

'emails' => ['mailto:' . urlencode($groupName) . '@group'],

For teams:

calendar/lib/Controller/ContactController.php

Line 340 in 1d94540

'member' => 'mailto:circle+' . $circleId . '@' . $circleMember->getInstance(),

Getting the display name from the circle ID is only possible there through a detour. How the frontend handles that today I do not (yet) know. On master, with a circle that has 3 direct members and a group (exposed as team) with two more users, it only writes this to the ICS:

ATTENDEE;CN=NBG2;CUTYPE=GROUP;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RS
 VP=TRUE;SCHEDULE-STATUS=3.7:mailto:circle+THPgVfWSLxHfTIeYA3Un3U5hMzUSqmV@
 nextcloud-dev
ORGANIZER;CN=admin:mailto:admin@example.net

and counts two attendees, even though I would expect 5 or at most 6 (the organizer is also in that team). On another instance with a mail server (NC33) the result is the same and no invitation goes out either. This looks like another bug to me. I am just going to assume it should work like contact groups, where the mailto ends up in MEMBER on the INDIVIDUAL ATTENDEE.

Point 1

And if we also fix the prefix check when adding another group that contains the same user, we will no longer get the same ATTENDEE more than once in the ICS (Test 2).

Offtopic

Does anyone know why inviting NC groups to an event is not supported right now?