fix: Redirect to the file's actual drive location instead of the personal drive - EXO-90214 - #2090
Merged
AzmiTouil merged 1 commit intoSep 23, 2026
Conversation
AzmiTouil
force-pushed
the
fix/exo-90214-document-location-redirect
branch
from
September 23, 2026 10:22
5e04354 to
1bea215
Compare
ahamdi
approved these changes
Sep 23, 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.
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'sbackToparam as the rawwindow.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 computedbackTo=/portal/dw/documents(the bug, reproduced exactly); the fix computesbackTo=/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).