JtxBoard CRASHes when opening attachment added from another device

[DodoLeDev]

Hi!

I've encountered a little problem... 😅

I have created a journal entry from the Kontact app and linked an image as attachment.
The sync with JtxBoard has been done without any problems! But when I try to open the attachment from this app, CRASH!! 💥

I'm aware of the size limit specified in JtxBoard when we want to add files, despite the fact that the file was 3x more than it (300Kb) 😅
But sync was done flawlessly 🤩

So, is the bug related to the file size limit or something else? 🤔

I dunno.

Sorry, but I can't provide crashlog for the moment, none of my logcat apps works correctly (they don't catch more logs than the ones related to those apps)

Hope this helps despite there is really few informations 😕

[patrickunterwegs]

Hey @DodoLeDev !
The file size limitation in jtx Board is just an artificial limit, theoretically there is no limit 😉 but practically the attachment is stored as Base64 string within the ics file. Now every time a sync is done, the whole file needs to be downloaded (with the attachment included) leading to more data consumption and longer processing times 😉 in the future I'd also make this limit configurable. And basically other solutions for attachments will be considered. This is just for explanation.

Regarding the crash: I think this is related to the file itself. Can you provide the file or give more information about the file type?
Or even better could you export the ics-file from the detail view in jtx Board and put it here in the attachment (if it also doesn't crash)? You could remove any sensitive information from the ics file before. Thank you! 🙂

[dilyanpalauzov]

And basically other solutions for attachments will be considered.

How about implementing RFC 8607 — Calendaring Extensions to WebDAV (CalDAV): Managed Attachments?

[patrickunterwegs]

Hello @dilyanpalauzov , thanks, Managed Attachments are already considered in the options for Attachment handling. However, at the moment we don't have the time and capacity to consider this topic more extensively, but we will come back to this in the future.