fix(web): [OCISDEV-1168] open files whose name contains a hash or question mark

[gauravsoni119]

Description

Cmd+Clicking (or middle-clicking) a file with a # in its name opened the space root instead of the file, and the top bar showed the space name rather than the file name. Files containing a ? were affected in the same way.

A file's path is carried in a route parameter, which the router percent-encodes when it builds the URL. That encoding was lost because the route was resolved twice, and resolving twice does not encode twice: the second pass rebuilt the URL from the parameter again, but with the encoding step skipped. For a file named #.txt:

• First resolve: parameter personal/admin/#.txt is encoded, then glued into a URL, giving /text-editor/personal/admin/%23.txt?fileId=abc123 — correct. The resolved route it returns still carries the parameter in decoded form.
• Second resolve: the finished URL is discarded and rebuilt from that decoded parameter, this time without encoding, giving /text-editor/personal/admin/#.txt?fileId=abc123.

The browser then reads everything from the # onward as a fragment, so the path became /text-editor/personal/admin/ and the whole query string — including the fileId needed to identify the file — was discarded before the app ever saw it. Plain left clicks appeared to work only because they never leave the app, letting it recover the file from that parameter.

getEditorRoute in useFileActions.ts now returns the raw route options instead of a pre-resolved route, so links receive them unresolved and the file name is encoded exactly once. <router-link> resolves internally, which is the single encoding pass. Hash and question mark remain valid characters in file names.

Affected consumers all funnel through this one producer (ResourceTable → ResourceListItem → ResourceLink, plus ActionMenuItem in the sidebar), so no component changes were needed.

Related Issue

• Fixes OCISDEV-1168

Motivation and Context

Files with a # or ? in the name could not be opened in a new tab at all — the malformed href silently dropped the fileId, leaving the app with nothing to resolve. Banning these characters was considered and rejected: existing files would stay broken, and desktop sync and WebDAV bypass web-side validation anyway. Preventing the malformed href addresses every entry point.

How Has This Been Tested?

• test environment: local oCIS instance
• test case 1: file with # in its name — Cmd+Click / middle-click opens the correct file in a new tab, and the top bar shows the file name
• test case 2: file with ? in its name — same
• test case 3: folders with # and ? in the name — open correctly (folders route through a different producer, folderLinkUtils.getFolderLink, which this change does not touch; checked for no regression)
• test case 4: unit tests, see the checklist below

Screenshots (if appropriate):

N.A.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Unit test added in useFileActions.spec.ts resolves the action's route through a real vue-router built from the same route definition web-app-text-editor registers, and asserts the encoded path for #.txt, a?b.txt and a#b?c.txt. Verified to fail without the fix.

🤖 Generated with Claude Code

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[mzner]

@gauravsoni119 I'm also a bit confused about this commit message

calens requires an entry to carry a URL with an extractable numeric ID, and
rejects the entry without one. The PR number is only known after the PR exists.

Is this related or was it by mistake?

[gauravsoni119]

Related, but it shouldn't have been a separate commit — sorry for the confusion. calens refuses to render a changelog entry that has no URL with an extractable numeric ID, and the PR number only exists once the PR is opened, so the URL got appended in a follow-up commit after pushing.

As a standalone chore commit it just read as noise. I've squashed it into the fix commit, so the PR is now a single commit and the URL is simply part of the changelog file.