The supportsActiveFilters variable was used but never defined, causing
the filtered/unfiltered results separation to fail silently.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
Show results from providers that don't support active content filters
(date/person) in a separate "Additional results" section with a note
explaining that some filters may have been ignored.
Changes:
- Add computed properties to separate filtered/unfiltered results
- Track filter compatibility using baseProvider for searchFrom providers
- Deduplicate results by resourceUrl across sections
- Skip in-folder results when at root to avoid duplicating Files results
- Fix providerIsCompatibleWithFilters to check correct filter properties
- Add styling for the unfiltered results section
Signed-off-by: nfebe <fenn25.fn@gmail.com>
When date range or person filters were applied, providers that didn't
support these filters were automatically disabled in the UI. This made
the in-folder filter appear auto-applied and prevented users from
searching non-compatible providers.
Remove automatic provider disabling logic from updateDateFilter(),
applyPersonFilter(), and removeFilter(). Content filters now apply only
to compatible providers via existing compatibility checks while keeping
all providers available for selection.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
This setting existed already for the legacy unified search.
This commit expose that setting to the new front-end, and
also ignore non valid requests in the backend.
We also take the opportunity to register the config in the lexicon.
Signed-off-by: Louis Chemineau <louis@chmn.me>
This removes:
- “enable” for settings
- “settings” for settings sections
- “all” when there is no obvious subset of items
- “show” and “open” for navigation actions
- “changes” for applying/discarding
- “to clipboard” when copying
- Explaining things that cannot happen
- Explaining things twice, right below each other
- Unnecessary technical jargon
- Text that sounds like marketing copy and serves no other purpose
Signed-off-by: kramo <git@kramo.page>
This commit introduces a change to prevent showing the load more button,
if the length of existing results is not equal to the requested limit (which implies
it is less than because we never expect it to be more)
Additionally, there is an enhancment to override provider filders passed to the find method.
This would improve speed.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
We hide **if** there is **no** notification.
We *do not* hide and *show the label* **if** there are notifications for
that application.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
The unified search modal was intended to be cleared when closed.
However, "UnifiedSearchModal" did not emit "update:query" when its
internal query value ("searchQuery") changed, so "UnifiedSearch.query"
was kept as an empty string. When the modal was closed "update:query"
was emitted with an empty string, which should have cleared
"UnifiedSearch.query" and that, in turn, should have cleared the modal.
However as "UnifiedSearch.query" was already an empty string the watcher
that updates "UnifiedSearchModal.searchQuery" from "UnifiedSearch.query"
was not triggered and the modal was not cleared.
As "UnifiedSearch.query" is now updated with the value of
"UnifiedSearchModal.searchQuery" the latter can not be trimmed when
updated from the former, as that would in turn also trim
"UnifiedSearchModal.searchQuery" and prevent to search for anything with
spaces at the beginning or end (even if those trailing spaces are just
temporary while writing something like "searched value").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Regression of https://github.com/nextcloud/server/pull/52703 where the
`>` was added by accident and thus the button has a wrong label
including the rest of the button HTML.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Maintain existing non-provider filters (like date and person filters) while
loading more results for a specific provider.
This now works as the provider data passed to the `newResults` array after search
is built dynamically and not manually, the result of a manual build was that the
`provider.filters` properpy which is used in the `find` method was being left out
in the providers pushed into the results array.
Fixes#52081
Signed-off-by: nfebe <fenn25.fn@gmail.com>
This commit changes the CSRF error message displayed in the login form to
provide more specific information to the user. Instead of the generic less helpful error.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
The main providers come from both the backend and client side plugins such as `in-folder` search.
The main providers may carry callbacks functions and other information that should be passed to the `filteredProviders`.
This is important because the current code does not make a distinction between `filteredProviders` and `providers`
rightly so, becuase they are the same thing!
Without the mentioned distinction above, sooner or later, we try to access a property on the `filteredProviders` which we
did not transfer with the manual property copy.
----
This fix prevents in-folder search from searching everywhere when "load more results" is clicked; Essentially ignoring the in-folder
search filter.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
The client-side plugin `in-folder` uses the `files` provider, this makes it
overlap with the main files provider itself.
This change follows eecda06f1a after it was discovered
that some apps/providers like `dav` use providers from another app like `contacts`
Signed-off-by: nfebe <fenn25.fn@gmail.com>
Signed-off-by: nextcloud-command <nextcloud-command@users.noreply.github.com>
Each provider may search from a particular app so we should use that for searching.
Before this commit, we used `provider.id` instead of `provider.appId` the problem with the previous
approach is that it forces the provider id to be a valid search provider (an app that supports search)
limiting the developers ability to use unique IDs to identify the different providers (especially plugin providers)
inside the places filter.
For example the Files search plugin "In folder" (search in folder plugin) was required to have id as `files` while the
files provider itself already has id as `files`.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
Ensure that the if a preview is available the maximum sizes are
respected (clickable area).
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
- Add default value to non-required Vue props
- Reformat function to async function if needed
- Add some documentation
- Allow `any` in places where it makes sense (tests)
- Order vue component sections as required
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Some filters are only available for certain providers, the UI should give the user
a hint to what providers such filters are available in.
Currently, if a filter (date or person) is not support by an a provider, the provider is
blurred out in the places dropdown.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
The content that can be renderered does *not* include HTML (see
`recommended` object).
But `v-html` was used, this is potentially dangerous, even though we
sanitize the translation values, so no urgent harm but better safe than
sorry.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
This adds a Vue implementation of the public page menu,
that is the menu that can be added using `PublicTemplateResponse::setHeaderActions`.
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Louis <louis@chmn.me>
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
