After much investigation and debugging it turned out the problem really was that KOrganizer was hiding declined and unanswered invitations. Fixed already in master and 24.02.

Fix back in October, will be released in 24.02 megarelease.

Just my five cents:

MRs for reference:

I have a NextCloud instance where I can simulate a bunch of users sharing calendars to investigate and test this.

Ah i und erstand what you mean now. Btw while checking this i found it confusing when i opened the incidenceeditor on an event in somone elses calendar. It did not show the correct organizer or even attendees. But this indeed might be caldav related. I would like to give you access to our radicale instance but i think it is in our VPN and so only the actual employees may access it (not even ingo)

The difference is that you can have an event in your calendar that you are neither an organizer or an attendee (think someone forwards you an invite) yet you will likely still want to receive a reminder for that.

In T6776#177536, @dvratil wrote:

Makes total sense, but I'd like to think about a more general approach if possible - what e.g. Google or Outlook do when you add someone else's shared calendar is they don't send you invite for their events either. But it's not because they wouldn't notify you about events where you are not an organizer, because in many cases you are just an attendee of someone else's meeting in your own calendar and you definitely want to get reminders for those.

Nah, forget it in that case. I might report a bug to SUSE in that case but we should not invest in fixing such things. I was planning to either use a self compiled PIM stack or Flatpack anyway.

Makes total sense, but I'd like to think about a more general approach if possible - what e.g. Google or Outlook do when you add someone else's shared calendar is they don't send you invite for their events either. But it's not because they wouldn't notify you about events where you are not an organizer, because in many cases you are just an attendee of someone else's meeting in your own calendar and you definitely want to get reminders for those.

You are right this looks like a bug in libical. I tried to downgrade to 3.0.16 but still can't reproduce the crash. But I also noticed that the line numbers from your backtrace do not align with upstream code. IIRC you are on Tumbleweed, right? They have some downstream patches in the parsing code (vcc.c) that probably cause the crash: https://build.opensuse.org/package/show/openSUSE:Factory/libical

Sorry took a while to download all the debug info. Maybe we have different libical versions and this is a libical issue.

Hi Andre,

I have another one, a bit hard to report upstream since it is related to the event and that contains personal information. So I will forward you the event in question privately. It is an ics file attached to a mail, I select "open with Korganizer" and when I hit "merge into existing calendar" it crashes with the debug output:

Merged to master for 23.12 as it includes new UI and translations strings.

Both PR merged into master, fix will be in 23.12 (the fix required cross-library API changes)

MRs:
https://invent.kde.org/pim/messagelib/-/merge_requests/143
https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/74

After some investigation it turns out there are several bugs in the thing that eventually produces an email with the counter proposal.

MRs:
https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/73
https://invent.kde.org/pim/incidenceeditor/-/merge_requests/49

After some investigation into what everyone else is doing, nobody seems to be using and supporting this property as of now. The big players (Google Calendar, Office365) abuse the Location field to store the URL for the onlin-meeting with alternative methods of joining the conference (e.g. dial-in numbers. etc) stored in the event description.

https://invent.kde.org/pim/eventviews/-/merge_requests/90

The changes have been merged and will be part of KDE Gear 23.12.

Thank you. I think it is good that we have now the time to attack some of these more difficult problems :) I don't understand the code there so don't expect a review from me.

PRs:
https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/67
https://invent.kde.org/pim/eventviews/-/merge_requests/88
https://invent.kde.org/pim/korganizer/-/merge_requests/103

I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"

in our study we've found that personal users often did not know that their software is capable of sending encrypted email. I blieve that most of them want a protected communication by default. (I may have seen surveys about this at some time as well.) If the recipient has published their public key, they are indicating that they can receive encrypted email.

I am not really a fan of this. I can respect this as a wish but it is currently not my vision. What you are really asking is basically that we lead the private users into sending encrypted mails without knowing that they are doing it. This will lead to frustrated users who then blame KMail for their bad user experience.

Linked from https://wiki.gnupg.org/EMailClients/KMail