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

Merged into master: https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/59 and should be available in Release 23.08.

I had to fix it anyway in order to be able to provide screenshot for the latest blog post about encrypting invitations :)

The expiry checker checks for expiry. It doesn't and shouldn't do anything else.

Another request for this would be that the for expired keys a --locate-key might be triggered. GpgOL currently does this in internal logic and this causes GnuPG to refetch the key e.g. from WKD if the key came originally from WKD. https://bugs.kde.org/show_bug.cgi?id=471911 I am not sure if the expiry checker already does this, but someone pointed me to the KDE bug and I will point back here because it makes little sense to fix this in the kmail resolver when we want to replace it.

Just as a background. This issue and others basically ended a project where dan and me worked on with a customer (you know who) to make Kontact from KDE 4 usable for them back in the day. The calendar was just too unreliable and this was one of the causes we identified. This does not mean that it will fix the unreliableness that we see with our calendars at work, but it is an issue that should be fixed.

https://invent.kde.org/pim/messagelib/-/commit/f8373bc09b228cc88577ec88b285c58a06122575

No bug, Use "cert" and not "certify".

Tracked at: https://bugs.kde.org/show_bug.cgi?id=363309

Thanks for the clarification. I'll ignore it in QGpgME then, too.

And after grepping for KEYEXPIRED in doc I have now found the DETAILS
documentation of which I was unaware until now. :-)

This is documented behaviour; see below. GPA ignores this status line.

• KEYEXPIRED <expire-timestamp> The key has expired. expire-timestamp is the expiration time in seconds since Epoch. This status line is not very useful because it will also be emitted for expired subkeys even if this subkey is not used. To check whether a key used to sign a message has expired, the EXPKEYSIG status line is to be used. Note, that the TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence of the letter 'T'.