checkInFromUrlAsync generates a bad filename inside the incoming folder
BIMServer version / Environment
1.5.150 and 1.5.157 on macOS 10.14, started from .jar release.
Describe the bug
ServiceInterface.checkInFromUrlAsync generates the wrong file name.
To Reproduce Steps to reproduce the behavior:
- Go to the BIMServer Console application;
- Use the
ServiceInterfaceto check in a new revision.
Expected behavior
The original file name was 2019-07-16-15-37-25-Villetta [AC21, QTY, 2X4].ifc so the expected file name should be 2019-07-19-15-07-13-933-2019-07-16-15-37-25-Villetta [AC21, QTY, 2X4].ifc (like it was with version 1.5.96) or something similiar (like with checkInFromFile).
Screenshots
Sample call (note that the spaces on the filename are escaped with %20):

checkInFromUrl from BIMvie.ws (it gives a different result)


Result with checkInFromFile from BIMvie.ws (it changes the file name since it replaces all the whitespaces with "_")

Additional context .
Other
it's not critical, but the incoming folder is useful if you have to migrate the project from an installation to another (it's faster to use the original IFC rather then to export the one stored in the database)
Sorry for the late reply.
I agree this is not critical, but it would be nice if it were to be more consistent. I think for migration purposes, it would be much nicer to actually store the final path/name to the stored incoming file in the Revision object (e.a. Revision.incomingFile). This way you don't have to infer it from the Revision.comment field, which could well be filled with something completely different.
What do you think of that?
checkinFromUrl
As for checkinFromUrl, that call actually has a "filename" field, which I think should always be used because not all URL's end with an actual filename (the URL is only used now if filename is empty).
It's not a problem! I've managed to work around the issue by chaning the checkIn procedure and by copying the file on a backup folder before doing the checkin.
The Revision.incomingFile could be a nice solution, so the client can query the BIMServer to get the filepath. Futrhermore the BIMServer could expose an API to download the original IFC file.
In my case the server's filepath is enough because both the client application and the BIMSever are installed on the same computer, so i can simply copy (or move) the IFC file from the incoming folder to a specific backup folder of the same machine.
Meanwhile, the suggested "download" API, it can be useful for debug purpose: if an user has a problem with an IFC file is always better to have the original file produced by the authoring software than the one generated from BIMServer.
For the checkInFromUrl, the filename field could me mandatory and could be used as part of the filename for the file in the incoming folder (i.e. <timestamp>_<filename>.ifc). From what i see from the screenshot the filename filed seems to have no effect on final filename but honestly, i don't rember very well.