-
Bug
-
Resolution: Fixed
-
Medium
-
3.1-beta2
-
None
- is duplicated by
-
CONFSERVER-18773 Office 2007 files are not working with Confluence. Get saved as zip files...
-
- Closed
-
-
CONFSERVER-18526 Download Microsoft Office 2007 format files using IE will change the extension to zip file
-
- Closed
-
- relates to
-
CONFSERVER-18951 Fix mime type for attachment file uploads.
-
- Closed
-
-
CONFSERVER-19045 Downloading an Excel Microsoft Office 2007 file in IE7/WinXP gives it a .zip extension.
-
- Closed
-
[CONFSERVER-17718] Downloading a .docx file in IE7/WinXP gives it a .zip extension (technically true but the average end-user wouldn't know that).
Is spreadsheet related bug is fixed as mentioned version of confluence which is 3.3?
Hi Maxime,
I added your request to the following issue: CONF-18951
The mime type for the macro enabled spreadsheet will be fixed in version 3.3 of Confluence.
Best regards,
Stefan Saasen
The issue is not fixed for file type XLSM , just to let you guys know as those macro enabled excel spreadsheets are a vital part of our usage of confluence. I urge you to fix this as soon as humanly possible.
For Confluence 3.1.2, please find attached a patch that includes fixes from CONF-17718 and CONF-19045: servlet.zip
You need to unzip the file so the directory structure is as follow: <confluence install>/confluence/WEB-INF/classes/com/atlassian/confluence/servlet/download and restart Confluence.
There will be three files in /download folder: AttachmentDownload.class, AttachmentDownload$MimeTypeTranslator$MimeTypeTranslation.class, AttachmentDownload$MimeTypeTranslator.class.
After you have unzipped the patch their path should look like this:
<confluence install>/confluence/WEB-INF/classes/com/atlassian/confluence/servlet/download/AttachmentDownload.class <confluence install>/confluence/WEB-INF/classes/com/atlassian/confluence/servlet/download/AttachmentDownload$MimeTypeTranslator$MimeTypeTranslation.class <confluence install>/confluence/WEB-INF/classes/com/atlassian/confluence/servlet/download/AttachmentDownload$MimeTypeTranslator.class
edit: the patch works for 3.0.x as well
Resolving as fixed - downloaded file type is now correct for docx/dotx/pptx/ppsx/potx files.
As mentioned above, this is a partial fix in Confluence 3.2, and comes with the following caveats:
1) The mime types in the database will still be incorrect if the browser sends them incorrectly. This fix only overrides the mime type at the point when the file is downloaded. So if there are plugins that rely on the mime type being correct on the server side, they will still encounter this issue (CONF-18951).
2) The fix does not apply to xlsx and xltx files, which will still download as .zip files (CONF-19045).
3) The fix does not apply to other files such as MindMap files (CONF-18951).
The Excel file extensions will be fixed in 3.2.1 (see CONF-19045).
QA reviewed in Confluence 3.2 on QA-EAC.
The issue is still reproducing for Excel files because the file extensions are incorrect.
- Excel spreadsheets are ".xlsx", not ".xslx"
- Excel templates are ".xltx", not ".xslt"
Hi Carol,
Sorry my comment probably wasn't making that clear: Updating the mime.types does not resolve this problem.
When you click on an attachment link, Confluence will use the mime type (aka content type) that the browser used for uploading the file.
E.g. if you use an older version of Internet Explorer the browser sends the content-type "application/x-zip-compressed" when you upload a .docx file and this is what Confluences stores.
If you then click on the attachment link the file open/save dialog will use the content type to determine the type of the file and in this case it will think that the file is a zip file.
If you use Firefox 3.6 for the file upload it correctly sends "application/vnd.openxmlformats-officedocument.presentationml.presentation" if you upload a .docx file.
The browser you use to download the file will use this mime type for the file open/save dialog and will detect that it is an Office XML file.
This problem occurs if the browser used to upload a particular file does not send the correct content type. Unfortunately this is not limited to Office XML files.
At least for Office XML files this will be fixed in the next version and I added another issue that addresses the underlying problem (see CONF-18951).
Best regards,
Stefan
OK, working fine now, cannot duplicate any of the problems from an hour ago. Still not feeling too confident - we'll just watch and wait for a few days, see how it goes. . .
I find the "fix" worked for downloads at first, now only sometimes, other times hangs the connection so the only recourse is to nuke the browser session and start over. In a new space created since the "fix" was installed, it doesn't work at all - back to the ".zip" substitution.
I cannot release my instance for demo or client use, this is core to my corporate users' experience, and the MS Office 07 file "open" problem / fix is so unreliable and persistent I've lost confidence in the platform altogether as an end user environment. I think it rises only to technical team level, if that.
That probably explains why this went un-noticed since November in the wide world of Confluence - which maybe is not so very wide, after all?? Confluence needs to stay in the technical workspaces for now, safely away from end users.
I'm using pure hosted version 3.1, IE7, MS Office 2007, but it's just not working. I am introducing an enterprise cloud environment for widespread services teams by starting with the hosted service - but with Confluence, I can't seem to get there from here Sad day.
Hi Wojciech,
Sorry, at this stage the fix will only address the attachment download of Office 2007 file types listed above.
Best regards,
Stefan
What I wrote above is true when you drag'n'drop files.
Using standard method it looks OK.
I have Confluence 3.1.1 and use IE7 on Windows XP.
To Stefan Saasen:
This problem is not limited to Microsoft Office 2007 files!
The same happens for MindManager files (mmap extension, technically speaking .mmap is a .zip file internally).
Does it mean it will be (will be?) fixed only for several file types??
Downloading a file with different exttension than uploaded one totally screws up Confluence usability...
My environment is IE 7.0.5730.13 with windows XP. If I apply the new mime.type I fix the "File upload" case but not the "Drag 'n drop upload".
Could you please provide a patch or say in which release it will be fixed?
Thanks,
Roberto
I looked into it and this is what I think is the problem:
The mime type (content type) of the file is whatever the browser sent during the upload of the attachment.
The mime type is stored in the database and is returned verbatim.
If a user clicks on a download link the browser will use the mime type (using the Content-Type header field) to determine the type of file.
If the browser that was used for the upload of the attachment did not specify the correct mime type, the database entry will contain the type.
I checked .docx (Word) and .pptx (Power Point) files with different browsers and only a few of them get it right.
.docx
Browser | OS | upload mime type | correct mime type | |
---|---|---|---|---|
Firefox 3.6. | Mac OS X 10.6.2 | application/vnd.openxmlformats-officedocument.wordprocessingml.document | File upload | ![]() |
Firefox 3.5 | Mac OS X 10.6.2 | application/vnd.openxmlformats-officedocument.wordprocessingml.document | File upload | ![]() |
Firefox 3.5 w/Gears | Mac OS X 10.6.2 | application/octet-stream | Drag 'n drop upload | ![]() |
Safari 4.0.4 | Mac OS X 10.6.2 | application/vnd.openxmlformats-officedocument.wordprocessingml.document | File upload | ![]() |
IE 6.0.2900.5512 | Windows XP | application/octet-stream | Drag 'n drop upload | ![]() |
IE 6.0.2900.5512 | Windows XP | application/x-zip-compressed | File upload | ![]() |
IE 7.0.5730.13 | Windows XP | application/octet-stream | Drag 'n drop upload | ![]() |
IE 7.0.5730.13 | Windows XP | application/x-zip-compressed | File upload | ![]() |
.pptx
Browser | OS | upload mime type | correct mime type | |
---|---|---|---|---|
Firefox 3.6 | Mac OS X 10.6.2 | application/vnd.openxmlformats-officedocument.presentationml.presentation | File upload | ![]() |
Firefox 3.5 | Mac OS X 10.6.2 | application/octet-stream | File upload | ![]() |
Firefox 3.5 w/Gears | Mac OS X 10.6.2 | application/octet-stream | Drag 'n drop upload | ![]() |
Safari 4.0.4 | Mac OS X 10.6.2 | application/vnd.openxmlformats-officedocument.presentationml.presentation | File upload | ![]() |
IE 6.0.2900.5512 | Windows XP | application/octet-stream | Drag 'n drop upload | ![]() |
IE 6.0.2900.5512 | Windows XP | application/x-zip-compressed | File upload | ![]() |
IE 7.0.5730.13 | Windows XP | application/octet-stream | Drag 'n drop upload | ![]() |
IE 7.0.5730.13 | Windows XP | application/x-zip-compressed | File upload | ![]() |
I'll add a fix for this that overrides the mime type for the attachment download for the following file extensions:
- docx: Word document
- dotx: Word template
- xslx: Excel spreadsheet
- xslt: Excel template
- pptx: Power Point presentation
- potx: Power Point template
- ppsx: Power Point slideshow
Hi,
this issue is still open in 3.1.2 and the quick fix isn't working if you upload the file using the drag 'n' drop panel (it works if you select the file using the "Choose File" button)
Thanks for the temp workaround Maleko.
We are having the same issue with .xlsx documents downloading as .zip extensions. Unfortunately we have a significant number of Office 2007 documents in our system, so your patch is not appropriate for us.
Having the files download as .zip's creates immense confusion with our users, and asking them to rename the file extension as a fix does not breed confidence in the system.
I added a vote to have this bumped up in the queue.
Here's a temporary workaround. I've attached a mime.types file that you will need to copy to your <Confluence-Install-Directory>/confluence/web-inf/classes directory. You will need to restart Confluence before the changes take effect. Also, you will need to re-upload your Office 2007 attachments before the attachments are able to be downloaded properly. This workaround is much more effective (less extra work needs to be done) for instances that don't already have a ton of Office 2007 attachments.
I am just scheduling demo's with corporate clients to show them exactly how and why they should trust Confluence and begin coordinating their business teams here.
Click-to-open their own attachments is the first thing they need. They are ALL on MS Office 2007.
This is an absolute show-stopper. A disaster. Today I have to decide whether to cancel the schedule and notify the attendees that there is an indefinite delay.
Any ETA on this? PLEASE TELL US WHEN / IF YOU WILL FIX THIS?? Thank you for anything you can do -
Carol Blanchar, CEO, Conexo
Michael,
Fair enough - I have upgraded this issue to Major, and I will bring it to the attention of the Confluence Product Manager.
Cheers,
Mark
Yes, you work around does work, but many of our users like (and only know) the click on the link and it opens - They print or close the file and that is that.
That will not work if the attachment was uploaded it with the drag and drop feature.
And worse, it does works until someone edits it with "edit in Office" - then we will get the question why did this work and now it doesn't?
This is a big feature for us (linking to MS-Office docs) and Internet Explorer is the most used browser on the internet - Were not asking you to drop everything and work on this right away but seeing the priority as minor and that this has been a known issue since 11/17/09 (three months ago and nothing has been done) doesn't give me any confidence that it is going to be fixed any time soon.
Michael Rometty
University of Michigan
There is a workaround, you can simply rename the .zip file to .docx, and it can then be opened. The new Office 2007 file types basically are zip files.
Cheers,
Mark
I agree with Robert, this lack of functionality is the main reason we are not upgrading from 3.0.1. If we could turn off this feature altogether we would upgrade, but since most of our people use IE - Upgrading will cause us problems by introducing a new feature - that doesn't work for most of our users.
Guys, how can you view lack of support of Office 2007 files as minor issue? Is there a work around for this? If this is not solved then it means I'm forced to move to sharepoint for documents.
Dear Suma Ramki,
Are you referring to
CONF-18951? Yes, that was fixed in Confluence 3.3.Best regards,
Stefan