Uploaded image for project: 'Magnolia UI'
  1. Magnolia UI
  2. MGNLUI-7017

Model content with file/binary properties

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Neutral Neutral
    • None
    • 6.2.15
    • framework
    • None

      As a project developer, I want to model content with file/binary properties so that editors can add images to content entries without leaving the form.

      ACs

      • support multiple concurrent fields with arbitrary property names
      • do not require complex configuration or custom code (save action, item resolution strategies)
      • support delivery with facilities to resolve links to those binaries
      • offer a clear content-type property type and/or a clear, non-deprecated field-definition to configure such properties and editing experience
      • resolve confusion about upload-field (deprecated) vs. DAM upload-field (not deprecated, also unintuitively doesn't upload to dam) vs. link fields.
      • be usable in dam workspace without further linking (see SUPPORT-13193)

      Technical points

      • $type: uploadField definition has been deprecated since 6.2.4, see Upload field and DAM upload field; caution blocks in both pages advise "not to use" these definitions in certain context, without explaining why.
      • We currently go through interesting gymnastics to cover our internal usage:

        While damUploadField is not deprecated, it is no longer annotated as a field type

        —which doesn’t prevent actual usage, just makes it uglier, see this.

      • we are free to upload to DAM behind the scenes if we feel like, and as long as developer and author experience do not suffer from this.

        Acceptance criteria

              Unassigned Unassigned
              mgeljic Mikaël Geljić
              DeveloperX
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: