-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Fix opening search results for comments #13227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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>
|
/backport to stable15 |
|
/backport to stable14 |
|
@danxuliu where do you search for comments? 🤔 |
|
@skjnldsv In the search box in the header of the Files app (the same place you use to search files). |
|
TIL comments are part of the search provider 😅 |
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. |
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.