request SVN tag
[ Problem ]
The issue reported in https://issues.alfresco.com/jira/browse/MNT-12913 is easily reproducible where content with a certain length URL is unable to be opened in SPP
[ Details ]
Investigating case 00256103 further it seems this the issue (fixed by
MNT-10773) is still reproducible where if a document's path/URL length is +-260 chars it can result in the error shown in the screen-shot attached.
[ Steps to reproduce ]
1- Create Site: "Helpdesk - Information Systems"
2- Create this folder structure in document library of this site :
Ryan Cloutier > Sales Ad Ops > Sales Process > 2014 Digital Campaign Reporting > Doner > Doner > Barclays
3- Take the attached file "2014 Doner - Barclays IO1 10280 Campaign Reporting - Aug.docx" and upload to the last subfolder
4- From a client, "Edit Online" this file.
File is opened in MS office and it is editable
File is unable to be opened and the following error message displays:
"The URL for this file is too long for the application. A temporary' copy of this file will be opened on your computer. You must save this copy as a new file."
- and then this message
"Could not start MS Office."
[ Analysis ]
I have added debug to actions.js and switched on client-side debug to show the onlineEditUrl variable length and string before a decision is made (whether it is > or < 260 and the URL being changed if it is > 260 chars). I have attached the minified version with the debug ('actions-min.js').
In testing, with the path to the document set as per the steps above, the char length is 235 (see below):
- this fails
However if we replace all the spaces in the document name with underscores:
- this works
If you increase the path length drastically for the document, for example adding another long folder:
Ryan Cloutier > Sales Ad Ops > Sales Process > 2014 Digital Campaign Reporting > Doner > Doner > Barclays > supacalafragalistic 123456789012345
Then this will push the char limit higher and work as normal:
[ Theory ]
The theory is here that characters like spaces are being encoded, when the 'onlineEditUrl' is being tested for length (as per
MNT-10773), it is checking it's pre-encoded length. So, if it comes up close to 260 and we decide to use the path, the chances are that any spaces in there will push it to greater than 260 chars and SPP will fail at that point.
It's difficult to prove this theory because the mortbay URL encoding will kick in after SPP has been initialised so won't show for the reproduction steps document above.
However a projected URL encoding for the document could be:
(which as it stands pushes this length from 235 to 254 chars), it's uknown if there if this is indeed the full URL so there may be additional chars.
[ Proposal ]
Based on the above theory we could do one of two things:
1. take the current 'onlineEditUrl' and convert it to an encoded URL before testing for > 260 chars
2. Change to using alternate edit online URL for all SPP URLs, negating any test for 260 chars.