[MGNLRES-187] Add upload action for new resource files Created: 06/Aug/15  Updated: 29/Mar/22  Resolved: 08/Sep/15

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.2

Type: Story Priority: Neutral
Reporter: Andreas Weder Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: ux
Remaining Estimate: 0d
Time Spent: 1d 7h
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLRES-212 Icon preview missing in upload field Closed
relates to MGNLUI-3566 UploadReceiver doesn't accept a file ... Closed
dependency
depends upon MGNLRES-206 Uploading a file under folders not ye... Closed
supersession
supersedes MGNLRES-207 Uploaded ftl are detected as applicat... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: Phase out in-place templating app
Sprint: Basel 9
Story Points: 5
Team: Nucleus

 Description   

I'd like to add a new action to upload an existing file to be added a resource file to make it easier to work with existing content, if working remotely. The action should ask the user for a file name and use the one of the uploaded file as default. More details here: https://wiki.magnolia-cms.com/display/UX/The+Resource+files+app#TheResourcefilesapp-Availableactionswhenselectingaresourcefile

Having an upload action also gives us more possibilites to fulfill our promise to "get a web dev going with his first site in a day". A tutorial can be written to work with a running instance such as the demo instance.

Acceptance criteria:

  • a new action allows to upload an existing file and places it in the currently selected folder (or root folder)
  • as a user I have the possibility to change the name of the resource file right after or before the upload. If feasible, take the name of the uploaded file as a default, but still allow to edit it.


 Comments   
Comment by Federico Grilli [ 30/Aug/15 ]

Some problems need still to be solved but I'd rather create follow-up issues because they seem to be out of the scope of this particular issue

  • uploading a file under not yet existing folders fails with NPE in FileTransformer at line #147
    • JCR session holding the path (transient, not yet saved) is "lost" upon uploading the file which result in node being null (a new session is used which isn’t aware of the path to the new resource)
      java.lang.NullPointerException
      at info.magnolia.ui.form.field.transformer.item.FileTransformer.getOrCreateFileItem(FileTransformer.java:147)
  • image editing:
    • what we should allow? Probably only changing name.
    • display preview in action bar like in old resources app?
  • uploaded ftl are detected as application/octet-stream and thus are not editable:
    • depends on mime type not defined under /server/MIMEMapping?
Comment by Aleksandr Pchelintcev [ 02/Sep/15 ]
  • OpenResourceAction (while you're at it)
    Resource resource = unwrapResource(resourceItem);
    // 1 - They are LayredResources normally, so you can rely on that
    String originName = resource instanceof LayeredResource ?
    ((LayeredResource) resource).getFirst().getOrigin().getName() :
    resource.getOrigin().getName();
    ..
    //2 - check that the Resource is from JCR with "((LayeredResource) resource).getFirst().getOrigin() instanceof JcrResourceOrigin"
    if ("jcr".equals(originName)) {
  • SaveUploadedResourceFileDialogAction - unclear logic
    if (property == null) {
    property = PropertyUtil.getPropertyOrNull(binaryNode, FileProperties.PROPERTY_FILENAME);
    ===> // If FILE_NAME property doesn't exist - throw Exception
    if (property == null) { throw new IllegalStateException("Expected to find either a [jcr:mime:type] or [fileName] property but none was found"); }

    else

    { ===> // If _FILE_NAME_ property exists - create MimeType out of _PROPERTY_EXTENSION_ ? return MediaType.create("text", "x-" + PropertyUtil.getString(binaryNode, FileProperties.PROPERTY_EXTENSION)); }
  • ResourcesContentConnector - not a very nice thing that we have to mix the jcrNodeIds with resource paths that we usually use as ids for content connectors.
    • might cause issues w/ selection/URL fragments etc
    • mentioning again - maybe delegation of transient resource creation/deletion to JcrResourceOrigin could be a good solution?
  • MVH: I'm not sure but seems like I had a conflicting situation w/ dialogs in a similar case
    • Since the legacy folder bootstraps the whole 'dialogs' node, a separate dialog bootstrap file (like you've added) somehow got lost for me - maybe got overwrtitten since it is on a higher folder level than the legacy ones?
    • Could you kindly check that?
Comment by Federico Grilli [ 02/Sep/15 ]

Addressed all issues in QA but ResourcesContentConnector. That is likely something to be delegated to JcrResourceOrigin as Sasha said above

Comment by Mikaël Geljić [ 04/Sep/15 ]

Just reopening to account for latest decisions:

  • Upload shouldn't go straight to a JCR adapter, we create the path/node in SaveAction in one step
    • => No need for specific CancelUploadedResourceFileDialogAction
    • => Similarly, no need to impl SupportsCreation on ResourcesContentConnector?
  • We try to keep adding/uploading logic close (e.g. auto-creation of parent dirs, resource node structure)
  • Still a bit unclear what to do with parent dirs when deleting a resource imo, although this could be re-iterated over later.
Comment by Federico Grilli [ 07/Sep/15 ]

One known issue to be solved separately in UI:

  • uploading under root doesn't show save and cancel buttons. Apparently this is due to
    info.magnolia.ui.framework.availability.shorthandrules.JcrRootAllowedRule.isAvailableForItem(Object) which should only care about JCR item ids
Comment by Ilgun Ilgun [ 08/Sep/15 ]

Discussed with fgrilli, found one issue.

given(user).addsTextFileWithNoSuffixNewAsResource();

when(dialog).opens();

then(dialog).doesNotReflectTheLocalFileName(); // problem one

when(user).savesDialogWithModifiedFileName();

then(dialog).isNotTakingThisModifiedNameIntoAccountAndSavesItAsUntitled(); // problem two

Comment by Federico Grilli [ 08/Sep/15 ]

Apparently this is the expected behaviour according to MGNLUI-3066 and the code at info.magnolia.ui.form.field.upload.UploadReceiver.getFileName(). We might ask Monsieur ehechinger if there's some particular reason why a file without an extension isn't accepted and it automatically changed as "untitled".

Generated at Mon Feb 12 06:48:15 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.