TL;DR
TemplateFieldService::extractFields() only proceeds for mimetypes in Capabilities::MIMETYPES β which holds ODF/legacy formats, not the OOXML ones. Since richdocuments defaults to doc_format=ooxml, the field-extraction/fill-in-dialog feature never fires for the default document/spreadsheet/presentation templates. No error, no log β it just silently returns no fields every time.
Details
Where: lib/Service/TemplateFieldService.php, extractFields():
if (!in_array($file->getMimetype(), Capabilities::MIMETYPES)) {
return [];
}
The gap: Capabilities::MIMETYPES (lib/Capabilities.php:17-38) contains only ODF and a handful of legacy/alternate formats (.odt, .ods, .odp, .odg, RTF, etc.). All OOXML/MS mimetypes (.docx, .xlsx, .pptx, .doc, .xls, .ppt, and their macro-enabled variants) live in the separate Capabilities::MIMETYPES_MSOFFICE constant (lib/Capabilities.php:40-62), which extractFields() never checks.
Why it matters: RegisterTemplateFileCreatorListener.php defaults to doc_format=ooxml (getAppValue(Application::APPNAME, 'doc_format', 'ooxml')), meaning the document/spreadsheet/presentation template types register with .docx/.xlsx/.pptx mimetypes out of the box. For any install on that default:
- User picks a custom template with fields defined.
- Frontend calls
listTemplateFields β TemplateManager::getTemplateFields() β TemplateFieldService::extractFields().
extractFields() hits the mimetype guard, returns [], unconditionally, regardless of whether the template actually has fields.
- Frontend's
fields.length > 0 check (apps/files/src/views/TemplatePicker.vue in nextcloud/server) is always false, so the "Fill template fields" dialog never appears.
The end result: the template form-filling feature (fields extraction + fill-in dialog) is effectively dead for any install using the default OOXML document format β the only way it currently works is if an admin has switched doc_format to odf.
Suggested fix: have extractFields() check array_merge(Capabilities::MIMETYPES, Capabilities::MIMETYPES_MSOFFICE), matching the guard already used in FileCreatedFromTemplateListener::handle().
Found while reviewing #5971, which is unrelated and does not need to block on this β this is a pre-existing, separate bug.
TL;DR
TemplateFieldService::extractFields()only proceeds for mimetypes inCapabilities::MIMETYPESβ which holds ODF/legacy formats, not the OOXML ones. Since richdocuments defaults todoc_format=ooxml, the field-extraction/fill-in-dialog feature never fires for the default document/spreadsheet/presentation templates. No error, no log β it just silently returns no fields every time.Details
Where:
lib/Service/TemplateFieldService.php,extractFields():The gap:
Capabilities::MIMETYPES(lib/Capabilities.php:17-38) contains only ODF and a handful of legacy/alternate formats (.odt,.ods,.odp,.odg, RTF, etc.). All OOXML/MS mimetypes (.docx,.xlsx,.pptx,.doc,.xls,.ppt, and their macro-enabled variants) live in the separateCapabilities::MIMETYPES_MSOFFICEconstant (lib/Capabilities.php:40-62), whichextractFields()never checks.Why it matters:
RegisterTemplateFileCreatorListener.phpdefaults todoc_format=ooxml(getAppValue(Application::APPNAME, 'doc_format', 'ooxml')), meaning the document/spreadsheet/presentation template types register with.docx/.xlsx/.pptxmimetypes out of the box. For any install on that default:listTemplateFieldsβTemplateManager::getTemplateFields()βTemplateFieldService::extractFields().extractFields()hits the mimetype guard, returns[], unconditionally, regardless of whether the template actually has fields.fields.length > 0check (apps/files/src/views/TemplatePicker.vuein nextcloud/server) is always false, so the "Fill template fields" dialog never appears.The end result: the template form-filling feature (fields extraction + fill-in dialog) is effectively dead for any install using the default OOXML document format β the only way it currently works is if an admin has switched
doc_formattoodf.Suggested fix: have
extractFields()checkarray_merge(Capabilities::MIMETYPES, Capabilities::MIMETYPES_MSOFFICE), matching the guard already used inFileCreatedFromTemplateListener::handle().Found while reviewing #5971, which is unrelated and does not need to block on this β this is a pre-existing, separate bug.