fix: Check file existence before using save as

[juliusknorr]

When using the "Save as" function you may end up saving files with the same name which did not lead to a expected copy then. This extends to check for existence before issuing the save as method with Collabora.

In the future a file picker could be used for the folder but we would need to extend that with a name input and further logic in the library so this is a smaller change that can be backported.

[moodyjmz]

@juliusknorr the code looks good. I see there are some build and merge issues.

Also, could you point me at something, or tell me how to test this?

[juliusknorr]

The failing test indeed seems related to the change as it is affecting the save as feature to save a document under a new name. However it seems to only occur in the "direct editing" mode.

This direct editing mode is used by the Nextcloud mobile clients to open office for editing in a webview:
https://github.com/nextcloud/richdocuments/blob/main/docs/mobile_editor.md

To manually test this you can use the steps from #4739 (comment)

Could you maybe take over and see if it is a valid failure and if so work on a fix?

Ping me if you need more assistance for getting this up locally or running tests locally.

[moodyjmz]

The failing test indeed seems related to the change as it is affecting the save as feature to save a document under a new name. However it seems to only occur in the "direct editing" mode.

This direct editing mode is used by the Nextcloud mobile clients to open office for editing in a webview: https://github.com/nextcloud/richdocuments/blob/main/docs/mobile_editor.md

To manually test this you can use the steps from #4739 (comment)

Could you maybe take over and see if it is a valid failure and if so work on a fix?

Ping me if you need more assistance for getting this up locally or running tests locally.

Yep, I can take over, I will try getting it up locally alone first - sometimes mistakes are good :)

[moodyjmz]

So my first go once setup

• create doc
• generate link
• open link in new private window
• try 'save as'
• get 'Error checking if file exists.'

curl --request POST \
  --url 'http://nextcloud.local/ocs/v2.php/apps/richdocuments/api/v1/document?format=json' -u admin:admin \
  --header 'Content-Type: multipart/form-data' \
  --header 'OCS-Apirequest: true' \
  --form fileId=[file id]

[moodyjmz]

import { getClient, getDefaultPropfind, resultToNode, defaultRootPath } from '@nextcloud/files/dav'

defaultRootPath is used to lookup the file, however it is undefined

[moodyjmz]

function getRootPath() {
  if (isPublicShare()) {
    return `/files/${getSharingToken()}`;
  }
  return `/files/${getCurrentUser()?.uid}`;
}

in node_modules/@nextcloud/files/dist/dav.mjs

Gives undefined as PublicShare is false

[moodyjmz]

Problem: When opening a document via a direct editing link (e.g. from the OCS API /api/v1/document) in an unauthenticated session (such as an incognito window to simulate the way mobile works - I have not looked at mobile), the "Save As" functionality was producing an invalid DAV URL: remote.php/dav/files/undefined/filename.docx.

Root cause: The defaultRootPath from @nextcloud/files/dav is evaluated once at module import time. It relies on getCurrentUser() from @nextcloud/auth, which reads data-user from the HTML element. In direct editing sessions (rendered as a @publicpage with the 'base' template), there is no authenticated browser session, so getCurrentUser() returns null and the path becomes /files/undefined.

Changed

1. DirectViewController.php — Added 'userId' => $direct->getUid() to the params passed to the frontend initial state. The direct editing token already stores the initiating user's ID, but it was never provided to the frontend.
2. SaveAs.vue — Replaced the static defaultRootPath import with a computed rootPath property that resolves the user ID at runtime, falling back to Config.get('userId') (from the backend initial state) when getCurrentUser() is unavailable.
3. SaveAs.vue — Wrapped the DAV file existence check in if (!Config.get('direct')) because direct editing sessions have no authenticated DAV session, so the stat() call would fail with NotAuthenticated. The backend handles filename conflicts itself (appending (2) etc.). A future improvement could use a dedicated API endpoint that validates the WOPI token to check file existence on behalf of the user.

[moodyjmz]

I left this open as I made some changes now - I think they are aligned with the original intent though

[juliusknorr]

Indeed I missed that we have no webdav access with direct editing. This is good enough for fixing the reported issue I#d say.