[MNT-14924] Upload new version with different file (mime) type does not update properties or .extension Created: 02-Oct-15  Updated: 02-May-18  Resolved: 04-May-16

Status: Closed
Project: Service Packs and Hot Fixes
Component/s: Share Application
Affects Version/s: 5.0
Fix Version/s: 4.2.7

Type: Improvement
Reporter: Will Taylor [X] (Inactive) Assignee: Closed Bugs (Inactive)
Resolution: Fixed Votes: 2
Labels: releasenotes
Remaining Estimate: 0 minutes
Time Spent: 1 week, 2 days, 5 hours, 7 minutes
Original Estimate: Not Specified

Attachments: PNG File New File Version Upload Work Flow.png     PNG File uploadNewVersion.PNG    
Issue Links:
Cloners
is cloned by MNT-16328 CLONE Cloud - Upload new version with... Closed
is cloned by MNT-16245 CLONE - Upload new version with diffe... Closed
is cloned by MNT-16430 CLONE - Upload new version with diffe... Closed
Duplicate
duplicates MNT-10987 No restriction for file extension whe... Closed
is duplicated by ALF-21590 Alfresco does not detect mime type ch... Closed
is duplicated by SHA-309 Document name not updated when a new ... Done
Problem/Incident
causes MNT-18305 Upload new version of an Edit Online ... Open
causes MNT-10987 No restriction for file extension whe... Closed
Related
relates to SHA-1549 Would like the ability to filter file... Done
is related to by ALF-21813 MIME type does not change when the co... Closed
is related to by MNT-16824 upload new version shows the confirma... Closed
is related to by MNT-18319 Behaviour introduced in MNT-14924 sho... Need Info
is related to by MNT-15024 Metadata overwrite policy can be set ... Closed
is related to by MNT-17620 Upload new version action for a dupli... Open
is related to by REPO-186 Decide on API behaviour when mimetype... Done
is related to by REPO-228 Update Node Content Done
is related to by MNT-14790 Inconsistent behavior in handling Upl... Closed
is related to by MNT-17666 AutoCAD mimetype lost when uploading ... Closed
is related to by MNT-18018 CLONE - 5.0.4 - Edit off line and Upl... Closed
Bug Priority:
Category 2
ACT Numbers:

QA, 00138590, 00489538

Build Location: https://releases.alfresco.com/Enterprise-4.2/4.2.7/build-00007

 Description   

Requirements


As an end user I want Alfresco to handle changes in filenames and Mimetypes gracefully so that when a new version is created that has a different file extension and/or a different Mimetype the transforming does not fail and downloads by other users can be opened easily.

Acceptance Criteria

  • Upload new version action goes straight to the file selection dialog in the users OS
  • There is no dialog where the user has to click Select button to choose the file to be uploaded
  • After the user has chosen a file a dialog appears
  • The dialog contains:
    • Title: "Uploading: <filename.ext>"
    • There is a X top right corner which closes the dialog, no changes are made
    • There are two columns, first labeled "Current File", second labelled "New File"
    • Under Current File these properties are listed: Current version, Filename.ext, Title, Mimetype, Last modified by and when
    • Under Current File an image is displayed that represents the mimetype
    • Under New File the Filename of the file being uploaded is displayed
    • Under New File the Mimetype of the file being uploaded is displayed (assumed from the file extension
    • Under New File the user is given the choice of whether the new version number will be a minor increment or a major increment
    • Under New File an image is displayed that represents the mimetype
    • There is a "Comments" text box which the user can enter comments into
    • There is a button called "Add this file as a new version"
    • There is a "Cancel" button
  • The Cancel button closes the dialog, no changes are made
  • The Add this file as a new version to the existing file button does the following:
    • If the filename is identical to the current version then the content is updated in the repository, the version number is incremented as per the users choice and any comments inputted are saved (i.e. what happens today), including updating the modified date & by
    • Where the filename is not identical then update the content, filename and mimetype in the repository also the version number is incremented as per the users choice and any comments inputted are saved (i.e. what happens today), including updating the modified date & by
  • The default selection is the Add this file as a new version button, so pressing enter key will trigger that button

    Original Text


    Steps to reproduce:
    1) upload powerpoint file.
    2) go to the powerpoint file document details page
    3) upload new version and select a word document
    3) refresh page and see increased version number and word document content
    4) Download file and try to open
    5) edit document properties and change mime type to word
    6) Download file and try to open
    7) Rename file and change extension from .pptx to .docx
    8) Download file and try to open
    9) upload new version of word doc
    10) revert to pptx version
    11) Check properties (also reverted to match the version reverted), however file name remains as .docx

Expected behaviour
As a minimum, so that transforms are not adversely affected, when uploading a new version, the MIME type should be checked and reset if needed - so that the transformations are attempted for the correct mime type and do not consume large resources trying to use the wrong conversion method.
As a possible improvement, it should also change the file name extension to match and record this as part of the version properties, so that it could be reset if the version is reverted... though this mainly seems to impact users that download the content not being able to open the file as the file format does not match the name.extension, so the client tries to open the file with the wrong application.

Actual result:
The files are uploaded and the mime-type doesn't change when the document format changes and the extension remains, causing the documents to be downloaded with the wrong extension, so that cannot be opened, and transforms attempted for the wrong mime-type.



 Comments   
Comment by Derek Hulley [X] (Inactive) [ 05-Oct-15 ]

I am presuming that the interface used is Share.
The repository does not second guess the mimetype once the file exists nor does it change the file extension; this is deliberate: the interface that performs the upload has the final say on what the document type is and the repository has to believe it; if a new binary is inserted into a document, it is not the job of the repository to rename the file or change the metadata around the file.

I would suggest that we flag this up at the UI (at most) but we cannot prevent a low-level (repo API) binary upload from pushing data in and nor can we magically change the filename.
In fact, the extension itself is not something that the repository really cares about other than providing tools to aid the clients in guessing what the mimetype and extension should be.

Comment by Will Taylor [X] (Inactive) [ 05-Oct-15 ]

With the upload of a different filetype as a version, other than the mime type for transforms on the server, the extension is used on download for the clients to determine which application to open the file with.
So when another file type is uploaded as a new version, the file name, file type name extension/mime type could be different... what should be changed?
File type name extension and mime type only or should the filename also be changed (if different)... or just warn the user that they have changed filetype and tell them what else to change, so that others may use the file?

Can the Share product owner clarify what should be done in this scenario?

Comment by John Knowles [X] (Inactive) [ 17-Dec-15 ]

MIME Type not updating is also described in MNT-10987; this seems to be the cause of Document Details failing to display the new version - which is a bug because of the regression since version 4.1.

In the case of the file extension, and even the file name, not updating we will have to enhance the upload new version mechanism to ask the user to confirm what they want to do:

  • The file you are uploading is a different format to the current version.
  • Continuing will update both the file name and file extension.

Will Taylor [X] this feels like an important enhancement to do due to customers reporting the problem, and the resulting problems that end users can get themselves into - can sustaining do this work?

Generated at Fri Apr 23 12:59:05 BST 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.