Release 26.5.54 on 15.09.2026

This release repairs the two process steps that copy the attachments of a source document onto the eDoc. Both reused one buffer for their whole loop, so on a document with several attachments only the first file reached the eDoc intact: one step rewrote its buffer without emptying it first and left the tail of a longer preceding file inside a shorter one, the other read the file content once before the loop and attached the first file's bytes under every following file name. Each attachment is now read and written on its own buffer, so every file arrives on the eDoc exactly as it is on the source document.

Bugfix

• Attach files from original document now writes each attachment with its own content. The step reused a single buffer across the loop and merely repositioned it to the start before every file instead of emptying it — and a buffer that is rewritten from the start is not shortened, so a file smaller than one written before it kept the trailing bytes of that earlier file and reached the eDoc corrupted, in most cases no longer openable by the recipient. Because the damage depends on the sizes of the files and the order they are attached in, a document whose attachments happened to grow from small to large came out correct, which made the fault look sporadic and hard to pin to a particular document. The buffer is now emptied before each file, so every attachment carries exactly its own bytes regardless of size or order (CHN-466)

• Attach files from inc. documents of original document now attaches the file that belongs to each name. The step read the content of the incoming document attachment once before it looped over the attachments, and that read is a snapshot of the record the step is positioned on at that moment — so every file after the first went out with the first file's content under its own file name, a mismatch that is not visible from the attachment list on the eDoc and only shows when the recipient opens the file. The content is now read inside the loop, per attachment, on an emptied buffer. The number of attachments taken over, which the step writes to the eDoc information log, was also always reported as 0 and now states the actual count. Both steps are a pure code change — no schema data is touched, so existing tenants do not need to update the schema from standard; eDocs already created with corrupted attachments are not repaired retroactively and have to be created again (CHN-466)