Bug #93695

Cannot override file upload mime-types completely

Added by Oliver Hader 10 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2021-03-10
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
Remote Sprint

Description

Form element definition for FileUpload in typo3/sysext/form/Configuration/Yaml/FormElements/FileUpload.yaml contains

allowedMimeTypes:
  - application/msword
  - application/vnd.openxmlformats-officedocument.wordprocessingml.document
  - application/vnd.oasis.opendocument.text
  - application/pdf

My specific form definition at fileadmin/form_definitions/something.form.yaml overrides settings since I just expect plain-text or CSV uploads:

-
  properties:
    saveToFileMount: '1:/form_uploads/documents/'
    allowedMimeTypes:
      - text/plain
      - text/csv
    elementDescription: ''
  type: FileUpload
  identifier: fileupload-1
  label: Document

However, allowedMimeTypes items are not completely overridden, but merged instead - some mime-types of the initial form element definition are kept - for this example I get:

  - text/plain
  - text/csv
  - application/vnd.oasis.opendocument.text
  - application/pdf

This is caused in TYPO3\CMS\Form\Domain\Model\FormElements\AbstractFormElement::setProperty() which implicitly merges those values. From my point-of-view it's most probably not required to apply initial settings from typo3/sysext/form/Configuration/Yaml/FormElements/FileUpload.yaml at all - however, I did not check/verify that.


Related issues

Related to TYPO3 Core - Bug #90188: Re-implement strict mimetype validationClosed2020-01-24

Actions
Is duplicate of TYPO3 Core - Bug #92309: Missing feature flag processing/checkClosedMathias Brodala2020-09-15

Actions
#1

Updated by Martin Kutschker 10 months ago

Furthermore it's not only mime types that "accept", well, accepts: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file#attr-accept

For better user experience we usually add the common file extensions to the attribute.

But yes, the implementation is broken. And also in the form editor it is not clear for an editor what mime types you get, when you select one or none for an upload field.

I think we could have a file type collection as intermediary. The file type lists all extensions and mime types associated eg with a PDF document. MIME types mean nothing to a user. File extensions maybe only for older Windows users.

#2

Updated by Bjoern Jacob 5 months ago

  • Related to Bug #90188: Re-implement strict mimetype validation added
#3

Updated by Bjoern Jacob 5 months ago

  • Sprint Focus set to Remote Sprint
#4

Updated by Mathias Brodala 5 months ago

  • Is duplicate of Bug #92309: Missing feature flag processing/check added
#5

Updated by Mathias Brodala 5 months ago

  • Status changed from New to Closed

This is actually a duplicate of #92309. In TYPO3v10 a feature flag has been introduced which allows disabling the default list of MIME types. This way a custom MIME type will be respected properly.

Also available in: Atom PDF