Uh oh!
There was an error while loading. Please reload this page.
Fix opening search results for comments - #13227
Conversation
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"OC.dirname" removes everything after the last "/", so a path without slashes is returned without changes. "result.path" does not include leading nor trailing "/", so when the path is for a file or folder in the base folder "OC.dirname(result.path)" returns "result.path". Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
danxuliu
commented
Dec 21, 2018
/backport to stable15 |
danxuliu
commented
Dec 21, 2018
/backport to stable14 |
skjnldsv
commented
Dec 22, 2018
@danxuliu where do you search for comments? 🤔 |
danxuliu
commented
Dec 22, 2018
@skjnldsv In the search box in the header of the Files app (the same place you use to search files). |
skjnldsv
commented
Dec 22, 2018
TIL comments are part of the search provider 😅 |
danxuliu
commented
Dec 22, 2018
Well, I think that nothing needs to be fixed there ;-) If you are looking for a file it makes sense that you can look also for the file based on comments written on it. |
skjnldsv
commented
Dec 22, 2018
Yes, you're totally right! 😉 |
backport to stable15 in #13253 |
backport to stable14 in #13254 |
OC.dirnameremoves everything after the last /, so a path without slashes is returned without changes.result.pathdoes not include leading nor trailing /, so when the path is for a file or folder in the base folderOC.dirname(result.path)returnsresult.pathinstead of an empty string.To test this just follow the steps in the acceptance tests open a search result for a comment in a file and open a search result for a comment in a folder named like its child folder (or just check the CI results :-P ).
There is another issue with opening search results for comments, though. This pull request fixes the link to the file, but theoretically clicking on a result should be intercepted before the link is opened, and instead of loading the new URL the file list should be simply updated with the desired file. However,
setFileListis called only on the search provider of files, so there will be no file list set in the search provider for comments and thus the click event will be handled by opening the link.Fixing that is more a structural change in the search (as the file list should be set for any search provider, it would not be enough to just set it explicitly on the search provider for comments), so that could be fixed for Nextcloud 16 in a different pull request if desired; this one is just a little bug fix (with its corresponding acceptance tests, of course ;-) ) to be backported to previous versions.