Sun, Nov 19
Just my five cents:
Thu, Nov 16
Sat, Nov 11
MRs for reference:
Oct 31 2023
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.
Oct 30 2023
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.
Oct 29 2023
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
Oct 27 2023
Oct 26 2023
Sorry took a while to download all the debug info. Maybe we have different libical versions and this is a libical issue.
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:
Oct 23 2023
Oct 7 2023
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)
Oct 2 2023
After some investigation it turns out there are several bugs in the thing that eventually produces an email with the counter proposal.
Oct 1 2023
Sep 30 2023
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.
Sep 4 2023
Aug 31 2023
Aug 29 2023
Aug 23 2023
Aug 17 2023
Aug 13 2023
The changes have been merged and will be part of KDE Gear 23.12.
Jul 31 2023
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.
Jul 30 2023
Jul 24 2023
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"
Jul 21 2023
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.
Jul 20 2023
Linked from https://wiki.gnupg.org/EMailClients/KMail
Jul 8 2023
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 :)