Unresolved — recording it so the next person does not spend the same hour.
State: FileRef column populated (fs://2026/08/06/<uuid>.docx?name=...), file present in
storage, hash field on the same fetch plan renders fine. The fileStorageUploadField bound
to that attribute renders as an empty "Upload" control. Inspecting the DOM:
tag: JMIX-UPLOAD-FIELD, value: "", hasValue: false
So the component never receives the value — this is not a rendering detail.
Tried and did NOT fix it:
- reloading the page (so it is not a stale
DataContext — though evicting the entity before
loader.load() IS needed for a different reason: the card otherwise shows pre-dialog state);
- removing
@PropertyDatatype("fileRef") from the attribute (the FileRefConverter is
autoApply, so the annotation is redundant; removing it changed nothing here).
Workaround shipped: an explicit download button using Downloader.download(FileRef).
Verified working end to end. Arguably better UX anyway — retrieving the finished document is
the primary action, and it should not hide inside an upload control.
What the skills should say either way: when an entity attribute holds a file, do NOT rely on
the upload component to display it. Add a download action and verify it by clicking it —
compileJava, clean test, and "the view renders" all pass while the file is invisible.
Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).
Unresolved — recording it so the next person does not spend the same hour.
State:
FileRefcolumn populated (fs://2026/08/06/<uuid>.docx?name=...), file present instorage, hash field on the same fetch plan renders fine. The
fileStorageUploadFieldboundto that attribute renders as an empty "Upload" control. Inspecting the DOM:
So the component never receives the value — this is not a rendering detail.
Tried and did NOT fix it:
DataContext— though evicting the entity beforeloader.load()IS needed for a different reason: the card otherwise shows pre-dialog state);@PropertyDatatype("fileRef")from the attribute (theFileRefConverterisautoApply, so the annotation is redundant; removing it changed nothing here).Workaround shipped: an explicit download button using
Downloader.download(FileRef).Verified working end to end. Arguably better UX anyway — retrieving the finished document is
the primary action, and it should not hide inside an upload control.
What the skills should say either way: when an entity attribute holds a file, do NOT rely on
the upload component to display it. Add a download action and verify it by clicking it —
compileJava,clean test, and "the view renders" all pass while the file is invisible.Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).