Sync saved searches across clients

[michaelstingl]

Is your feature request related to a problem? Please describe.

ownCloud iOS app 12.0+ comes with a very fancy search feature:

• [feature/new-search] New search experience for version 12 ios-app#1142

Users can combine multiple search parameters, then save this search to access it later again.

It would be super-awesome, if users could see the same search results as a shortcut in other clients, for example in the left sidebar in ownCloud web. (owncloud/web#7691)

Describe the solution you'd like

oCIS would need to provide a new API/endpoint, where such search queries could be saved and accessed from all clients. (per-user)

Describe alternatives you've considered

File-based approach inside the WebDAV tree: iOS app could upload a hidden JSON file in a hidden .search folder.

Additional context

See screenshots and example search queries in owncloud/ios-app#1142

[felix-schwarz]

Learnings from iOS implementation

Learnings from owncloud/ios-app#1142 that might help with this feature:

Parsing

When a user enters a search term, it is processed in several steps. By example, based on :today cupola (search files with "cupola" in the name, last modified today):

• Segmentation, segments the string, respecting quotation marks: turns :today cupola into [":today", "cupola"]
• Tokenization, turns the segments into objects (henceforth "search elements"):
  • looks for localized versions of special terms like :today and normalizes them into the English form, f.ex. :heute is turned into :today.
  • :today is turned into a search element filtering for the current day, f.ex. lastModified >= "2022-09-27 00:00:00", lastModified < "2022-09-28 00:00:00"
  • cupola is turned into a search element filtering for the file name: fileName contains cupola
  • each search element also gets a localized description for displaying to the user, f.ex. :today is turned into [ iconName: "clock", localizedDescription: "heute" ]
  • each search element also stores the string from which the search element was generated (originalSearchTerm)

Usage of Search Elements

The Search Elements coming from Parsing allow usage in different contexts:

• iconName and localizedDescription are used for:
  • representation as tokens in the search field
  • comparing two Search Elements for equality: if iconName and localizedDescription are equal, so is the criteria they search for, regardless of how it was initially expressed (f.ex. :today could also be expressed as :0d (since zero days)). This is useful to f.ex. determine which search filters should be shown as selected in the UI.
• the item's field to be filtered and the logical operation to be used are used for:
  • generation of SQL code to SELECT only matching items
  • generation of closures that accept item objects and return if they match the criteria (used for f.ex. live updates to search results as changes are made on the server)
• recreation of the search term by re-joining the originalSearchTerms from the Search Elements as a string
• creation of UI elements for filter selection, f.ex. :today can be parsed into a Search Element, whose iconName and localizedName can then be used to create a menu element the user can select to add that term to the search

Persistance

Saved searches are stored in records with the following fields:

• uuid: random UUID generated on object creation, used for referencing a specific saved search (f.ex. for storage, applying and deletion)
• name: (optional) name given by the user
• type: either template or view (see below)
• seachTerm: containing the unparsed or re-joined (see above) search term entered by the user
• scope: the scope of the search:
  • folder: search only items in the current folder (non-hierarchic)
  • tree: search only items in the current folder and its subfolders (hierarchic)
  • drive: search only items in the current space
  • account: search items in the entire account / all "mounted" spaces
• location: where a search was started, described as (only for views):
  • driveID: the space's drive ID (only for folder, tree, drive scopes)
  • path: the path inside the drive (only for folder, tree scopes)

The searchTerm is stored as a simple string because that makes it portable and ensures that :today always means the current day, not the day the search was saved (as would happen when saving the Search Elements, as :today is parsed into f.ex. lastModified >= "2022-09-27 00:00:00", lastModified < "2022-09-28 00:00:00"`).

Search templates and search views

• Search templates: save only the searchTerm and scope, but not the location. They can be selected only in the context of the search field and allow to apply the same set of search filters to different locations. If I f.ex. want to find only files last modified today, I could save a template for :file :today - and then re-apply the same search + scope in a different folder.

• Search views: save the full set of information, allowing to create a "smart view" of a set of items determined by logical criteria and not (necessarily) location. If someone wanted to have a view of all pdfs last modified in the current week in the Accounting space, they could create a search view with scope = "drive", location.drive = "ae57q…", searchTerm = ":week :pdf".

Search expressions

A list of supported search expressions by the iOS app is part of owncloud/ios-app#1142.

API proposal

An API could offer four endpoints:

• add: for adding a saved search (based on the format outlined in Persistence)
• edit: for replacing a saved search with another one, based on the UUID
• delete: for deleting a saved search, identified by its UUID
• list: returns a list of saved searches

Ideas

• saved searches could be saved either for just the user, a group or globally
• saved searches could be used for implementing
  • "Smart Spaces" (spaces containing just matching items)
  • "Smart Shares" (public or private shares containing just matching items)
  • "Smart Tags" (tags automatically being applied or removed based on whether they match the criteria or not)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.