fix: Resolve the personal drive page from the current drive, not the user home page - EXO-90214 - #2091
Merged
AzmiTouil merged 1 commit intoSep 24, 2026
Conversation
…user home page - EXO-90214 The personal branch of getParentFolderUrl, and the two sibling constructions in DocumentInfoDrawer, built the drive URL as eXo.env.portal.defaultPath + /dashboard/drive. defaultPath is the user's home page (UserPortalConfigService.getUserHomePage), so a user whose home is People was sent to /portal/dw/people/dashboard/drive/... after "Go to documents" in the ONLYOFFICE editor. getPersonalDriveUrl() replaces the three constructions: the current pathname truncated at /Private when inside the personal drive, the current pathname when the Documents application is on the page, and the addon's own global SYSTEM node /portal/<metaPortal>/documents otherwise, the same target DocumentPermanentLinkPlugin and NotificationUtils use. A file at the drive root points at the drive page itself. No query string is added to backTo: EditorPortlet passes it through HTMLSanitizer.sanitize, which encodes "=" as "=". The folder still opens because initSettings forces the folder view on the personal drive before getDocumentDataFromUrl reads the path.
ahamdi
approved these changes
Sep 24, 2026
AzmiTouil
added a commit
that referenced
this pull request
Sep 25, 2026
…user home page - EXO-90214 (#2092) * fix: Redirect to the file's actual drive location instead of the personal drive - EXO-90214 (#2090) Fixes the redirect reported in EXO-90214 Repro: open My Workspace > Drive, browse into a space via "Lecteurs d'espace", open an ONLYOFFICE document, click "Go to Document" (top right) — lands on the personal Documents treeview instead of the file's actual space location. Root cause: DocumentsFileNameCell.openInEditMode() / openInReadOnlyMode() build the editor's backTo param as the raw window.location.pathname, duplicating (and diverging from) the drive-aware logic that $documentsUtils.getEditorUrl(file, mode) already implements correctly elsewhere in this app (DocumentsMain.vue, FileSearchCard.vue, activity attachments…). "My Workspace > Drive" browses into a space's drive as a pure client-side SPA — the URL never leaves /portal/dw/documents, even while viewing a space's files — so the raw-pathname shortcut always points back to the personal drive regardless of where the opened file actually lives. Fix: replace the duplicated URL construction with the existing $documentsUtils.getEditorUrl(file, mode) helper, matching the pattern already used everywhere else file-open actions are wired. Verified live against a real file (/Groups/spaces/test_space_perf_1/Documents/...) browsed from "My Workspace > Drive > Lecteurs d'espace": old code computed backTo=/portal/dw/documents (the bug, reproduced exactly); the fix computes backTo=/portal/g/:spaces:test_space_perf_1/documents (correct). Full-repo sweep confirms no other occurrence of the same raw-pathname pattern. Classification: N3 (frontend-only, no REST/DAO/schema/ACL surface). (cherry picked from commit e2dc570) * fix: Resolve the personal drive page from the current drive, not the user home page - EXO-90214 (#2091) The personal branch of getParentFolderUrl, and the two sibling constructions in DocumentInfoDrawer, built the drive URL as eXo.env.portal.defaultPath + /dashboard/drive. defaultPath is the user's home page (UserPortalConfigService.getUserHomePage), so a user whose home is People was sent to /portal/dw/people/dashboard/drive/... after "Go to documents" in the ONLYOFFICE editor. getPersonalDriveUrl() replaces the three constructions: the current pathname truncated at /Private when inside the personal drive, the current pathname when the Documents application is on the page, and the addon's own global SYSTEM node /portal/<metaPortal>/documents otherwise, the same target DocumentPermanentLinkPlugin and NotificationUtils use. A file at the drive root points at the drive page itself. No query string is added to backTo: EditorPortlet passes it through HTMLSanitizer.sanitize, which encodes "=" as "=". The folder still opens because initSettings forces the folder view on the personal drive before getDocumentDataFromUrl reads the path. (cherry picked from commit 4bae48e)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up of #2090 for EXO-90214 — personal documents case
From My Workspace > Drive, opening a personal ONLYOFFICE document and clicking "Go to documents" redirected to
/portal/<user-home-page>/dashboard/drive/Private/Documents(for example/portal/dw/people/dashboard/drive/...when the home page is People) instead of/portal/myworkspace/dashboard/drive/Private/Documents.Root cause.
getParentFolderUrl(personal branch) and the two sibling constructions inDocumentInfoDrawer.vuebuilt the drive URL aseXo.env.portal.defaultPath + /dashboard/drive.defaultPathis the user's home page (UIPortalApplication.gtmpl->UserPortalConfigService.getUserHomePage(userName)), not the My Workspace site. Introduced by EXO-86459 (#1966).Fix. One helper,
getPersonalDriveUrl()inDocumentsUtils.js, replaces the three constructions:/Private): the pathname truncated there — back to the drive page the user came from;/portal/<metaPortal>/documents, the same targetDocumentPermanentLinkPluginandNotificationUtilsuse server-side;/Privatesuffix.Not done, on purpose: no
?view=folderinbackTo.EditorPortletpassesbackTothroughHTMLSanitizer.sanitize, which encodes=as=(executed against the 7.3 bundle jars). The folder still opens:initSettingsforces thefolderview on the personal drive beforegetDocumentDataFromUrlreads the path. The final URL is therefore.../dashboard/drive/Private/Documents?updated=true.Verification. Throwaway Node harness (not committed, per the frontend testing norm) over 9 scenarios — My Workspace drive root and sub-folders, global documents page, dw activity stream, space page, file at Private root, folder directly under Private, space file via space drives: all pass on the fix; 8 of 9 fail on the current code (the space-file case is unchanged). ESLint clean on the added lines.
Classification: N3 — frontend only, no REST/DAO/schema/ACL surface.
Knowledge: none — two facts worth a
domains/documents.md§14 entry (defaultPathis the user home page;backTocannot carry a query string) to be proposed as a corpus PR separately.🤖 Generated with Claude Code