This patch fixes the logic to allow SaveAs operations.
As the wopiserver does not know if a public share (where a file was opened) can be written to, that is it's a shared folder, the SaveAs operation is now offered only if the user is authenticated, otherwise only a "Download a copy" is possible, unless the VIEW_ONLY mode was used. The previous optimistic approach can lead to files successfully written (on behalf of the owner) to the shared folder, but inaccessible by the user, that is asked to login after the SaveAs operation.
For authenticated users, the behavior remains unchanged: if the shared folder is writable, a SaveAs operation will write a file in the same folder. Otherwise, the file is stored in the user's home folder, identified via the homepath configuration variable (the conflictpath deprecated parameter is now gone). If the backend does not allow to address absolute paths, then the SaveAs operation will be failed in the latter case.
This patch fixes the logic to allow SaveAs operations.
As the wopiserver does not know if a public share (where a file was opened) can be written to, that is it's a shared folder, the SaveAs operation is now offered only if the user is authenticated, otherwise only a "Download a copy" is possible, unless the
VIEW_ONLYmode was used. The previous optimistic approach can lead to files successfully written (on behalf of the owner) to the shared folder, but inaccessible by the user, that is asked to login after the SaveAs operation.For authenticated users, the behavior remains unchanged: if the shared folder is writable, a SaveAs operation will write a file in the same folder. Otherwise, the file is stored in the user's home folder, identified via the
homepathconfiguration variable (theconflictpathdeprecated parameter is now gone). If the backend does not allow to address absolute paths, then the SaveAs operation will be failed in the latter case.