Hi
We have finally made the move from FGL 3.21 to 5.01 but have noted a behaviour we cannot explain when using the launchURL front call in conjunction with ui.Interface.filenameToURI to display stored documents.
We have a centralised function to do this as all documents are stored in a single document archive. The function is as below:
#+
#+ View a document by its ID
#+
#+ This function allows the user to download a document for viewing
#+
#+ The public record will be set holding the document ID and its actual name
#+
#+ Documents are stored by ID in an archive folder (the root of which is held in environment variable: FGL_DOCUMENTROOT)
#+ IDs are prepended with zeros to make them 12 characters in length, e.g. 215168 becomes 000000215168
#+ The folder structure for the above document is then:
#+
#+ $(FGL_DOCUMENTROOT)/000/000/215/000000215168
#+
#+ @return Nothing
#+
function sys_viewDocumentByID()
define sFileSource,
sFileDestination,
sDocumentUri string
if p_documentR.documentid is null then
return
end if
if p_documentR.documentname is null then
return
end if
# Get the full path to the document within the archive
let sFileSource = sys_getDocumentPath(p_documentR.documentid)
if sFileSource is null then
return
end if
# If using GBC, copy the document to the temporary area, renaming at the same time
# If all is well, get the URI and make the front call
if ui.Interface.getFrontEndName() = "GBC" then
try
let sFileDestination = os.Path.join(g_tmpServerDir.trim(), p_documentR.documentname.trim())
if os.Path.copy(sFileSource, sFileDestination) then
let sDocumentUri = ui.Interface.filenameToURI(sFileDestination)
call ui.Interface.frontCall("standard", "launchURL", [sDocumentUri], [])
end if
catch
call sys_showMessage(%"Error", sfmt(%"Unable to download file %1 to %2 (%3)", sFileSource, sFileDestination, status), "")
end try
return
end if
try
let sFileDestination = g_tmpClientDir.trim(), g_clientPathSeperator.trim(), p_documentR.documentname.trim()
call fgl_putfile(sFileSource, sFileDestination)
call sys_launchDocument(sFileDestination)
catch
call sys_showMessage(%"Error", sfmt(%"Unable to download file %1", sFileSource)||CRLF||sfmt("To: %1", sFileDestination), "")
return
end try
end function
For the time being we are able to run our codebase using FGL 3.21 or 5.01, hence the check for the front end type.
The above works well when the filename of the document has no spaces, e.g. image01.jpg, but fails when there are spaces.
For example, a filename of "Meeting Report.pdf" will fail. The result is the following URI, for which we get a bad request response in the browser:
https://app.alsico.co.uk/gas/ua/ft/6f73f925533f0d5470e57ba6ea7b762a/fgl-files/82966/Meeting%20Report.pdf?t=1746363820;s=461534;charset=UTF-8However, if we replace the spaces with an underscore, i.e. "Meeting_Report.pdf", this results in a URI such as below, which works:
https://app.alsico.co.uk/gas/ua/ft/831139bc472031110b9fe19ea07f7add/fgl-files/82994/Meeting_Report.pdf?t=1746363908;s=461534;charset=UTF-8Can anyone see any issues in the above code? Though the workaround is fine, it would be better for us not to have to manipulate the file name.
Thanks in advance
Gary
