When clicking a webcal:// URL (e.g. Facebook's "Export" feature) and selecting, "Open in KOrganizer", KOrganizer will ask if you want to import the calendar into another calendar or create a new calendar. Importing into an existing calendar works flawlessly, but creating a new calendar creates an iCal file Akonadi resource that points to the path at the end of the URL (e.g. "/ical/u.php" or "/ical/b.php"). The calendar is not downloaded and the events do not populate. It should be noted that using the full URL of the webdav:// resource in the iCal file Akonadi resource configuration works. Reproducible: Always
Still an issue. The link should "subscribe" to the calendar (korganizer gets the url) and not just download it once (korganizer just gets the ics file). (webcals:// for https support would also be nice.)
I noticed "korganizer -i http://server.domain/folder/file" is actually not loading anything. The problem is, the arguments to korganizer are wrapped in a "KUrl" and only ".path()" is passed to "importIntoNewResource". I changed it to pass ".url()" instead... now the calendar is imported correctly. The other problem is the "webcal.protocol" file. It just registers "kio_http" for webcal links and then starts korganizer (according to mime type) with the file. This needs to be removed and instead a "webcal.desktop" file must be created to pass the url to korganizer... I think the protocol must be changed in this desktop file from webcal to http (and webcal to https).
Created attachment 91862 [details] pass full url and translate webcal(s) The webcal.protocol still needs to be replaced by webcal.desktop/webcals.desktop
Created attachment 91863 [details] example webcal.desktop Similar for webcals.desktop. Just pass the url to korganizer for webcal:// urls.
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.