Bug 451975

Neither on the main "my itinerary" view or inside a flight i can see the departure and flight time, i have to go to actions > show flight "ticket" (sorry the app is in spanish and i cannot set another language, which is another feature request maybe) to get to see the full information

The QR code shown is only of one type, other apps shows several types, because maybe the airport tries to scan a specific type. For example, the code shown in my ticket is of barcode type

* Notifications for the next actions

Yep, already planned.

* Generating calendar events

Code for this exists and is used in the KMail plugin, but it's not available inside the app yet indeed.

* Manually adding elements

Definitely needed as a fallback, currently being done for trains backed by online journey queries, for flights we don't have that so that would probably need to be a full free-form entry.

* Flight times

This sounds like the import was only based on the boarding pass barcode (those contain only the day of flight, not the time, and e.g. no airport names). If the details are in the Apple wallet pass that was apparently the source here, it's probably a small extractor fix to get to that, given the source file.

If times are properly extracted they will show up in the timeline, which should fix the described problem.

* Barcode formats

We try to preserve the format found in the source. Offering a way to change the format would be
straightforward, as we store the content rather than the barcode image anyway. However so far all airport scanners I have encountered support at least QR, Aztec and PDF417.

Hello,

I second the need to be able to send information to the calendar from the Android application.

I use KDE Itinerary for SNCF tickets, which are not attached to the email they send.
So, instead I download the ticket to a folder sync through Nextcloud, and on my phone I import the ticket with the app. This way all the information is in the app (and I have the original ticket as a fallback on my phone, I would like it if KDE itinerary stored the original PDF and allowed to consult it, but that’s another subject).
Main problem with this workflow is that the information is not added to my calendar.

Is an integration in Okular planned and how hard would it be? (either autodetecting like kmail, or run by clicking a menu action)

* Calendar integration: yep, needed and wanted for sure :)

* Storing PDF tickets: This should actually happen already, on the details page of a train trip the context menu on the right contains a "Documents" entry, and that should get you to a page that lists the corresponding PDF.

* Okular integration: Talked to Albert from the Okular team, Okular currently has no infrastructure for doing that kind of content analysis and showing extra content somehow embedded in the document view. So this would need some work on Okular itself first.

(In reply to Volker Krause from comment #5)
> * Calendar integration: yep, needed and wanted for sure :)

Great to hear

> * Storing PDF tickets: This should actually happen already, on the details
> page of a train trip the context menu on the right contains a "Documents"
> entry, and that should get you to a page that lists the corresponding PDF.

Oh, nice. It does not work though with muPDF.
I see the document list with the name of what I imported. clicking the name does nothing.
Clicking the dots shows an open icon, and clicking this icon asks me with what I want to open the document. I select mupdf, and I get «Cannot open document». If I select Pdf Viewer Plus it does open the PDF. The colors are inverted but I suspect this is a feature of this application, I never use it.

> * Okular integration: Talked to Albert from the Okular team, Okular
> currently has no infrastructure for doing that kind of content analysis and
> showing extra content somehow embedded in the document view. So this would
> need some work on Okular itself first.

Ok.
Reading https://www.volkerkrause.eu/2020/01/18/kde-itinerary-nextcloud-hub-integration.html it says "During the Nextcloud Hackweek last week we also extend the command line tool to produce iCal output, to avoid some code duplication for the calendar integration and ensure compatibility with the KDE Itinerary app. These changes didn’t make it into the current release packages, but should become available with the next update."
Were those changes merged in? If there is a command line tool to process a PDF and add it to a calendar, it would help integrating that with applications that allow calling script (I thought it was the case of Dolphin but I cannot find the option right now… but I could use open with -> and a script I suppose. Or a terminal.)

(In reply to Côme Chilliet from comment #6)
> Oh, nice. It does not work though with muPDF.

I can confirm the muPDF problem. Other PDF viewers work, and muPDF can open the same file itself just fine. So this is indeed specific to the Itinerary <-> muPDF interaction, but no idea yet what might be causing this.

> Reading
> https://www.volkerkrause.eu/2020/01/18/kde-itinerary-nextcloud-hub-
> integration.html it says "During the Nextcloud Hackweek last week we also
> extend the command line tool to produce iCal output, to avoid some code
> duplication for the calendar integration and ensure compatibility with the
> KDE Itinerary app. These changes didn’t make it into the current release
> packages, but should become available with the next update."
> Were those changes merged in?

Yes, that is available in the command line extractor. `kitinerary-extractor -o ical ticket.pdf` prints iCal to the standard output, identical to the one the KMail plugin produces as well.

(In reply to Volker Krause from comment #7)
> Yes, that is available in the command line extractor. `kitinerary-extractor
> -o ical ticket.pdf` prints iCal to the standard output, identical to the one
> the KMail plugin produces as well.

Oh, that’s good news.
But it seems this binary is not in the kitinerary package for ArchLinux though. I will report the problem to them.

(In reply to Côme Chilliet from comment #8)
> But it seems this binary is not in the kitinerary package for ArchLinux
> though. I will report the problem to them.
If that's indeed missing that would be a problem, as that executable is also used to isolate KMail from processing untrusted PDF attachments. However, note that it's usually not in the standard search path, here it's e.g. in /usr/lib64/libexec/kf5.

(In reply to Volker Krause from comment #9)
> (In reply to Côme Chilliet from comment #8)
> > But it seems this binary is not in the kitinerary package for ArchLinux
> > though. I will report the problem to them.
> If that's indeed missing that would be a problem, as that executable is also
> used to isolate KMail from processing untrusted PDF attachments. However,
> note that it's usually not in the standard search path, here it's e.g. in
> /usr/lib64/libexec/kf5.

You are right this is it, it is in /usr/lib. It should be in bin is my opinion.