felix-schwarz
commented
1 year ago Learnings from iOS implementation
Learnings from https://github.com/owncloud/ios-app/pull/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 cupolainto[":today", "cupola"] - Tokenization, turns the segments into objects (henceforth "search elements"):
- looks for localized versions of special terms like
:todayand normalizes them into the English form, f.ex.:heuteis turned into:today. :todayis 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"cupolais 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.
:todayis turned into[ iconName: "clock", localizedDescription: "heute" ] - each search element also stores the string from which the search element was generated (
originalSearchTerm)
- looks for localized versions of special terms like
Usage of Search Elements
The Search Elements coming from Parsing allow usage in different contexts:
iconNameandlocalizedDescriptionare used for:- representation as tokens in the search field
- comparing two Search Elements for equality: if
iconNameandlocalizedDescriptionare equal, so is the criteria they search for, regardless of how it was initially expressed (f.ex.:todaycould 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
SELECTonly 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)
- generation of SQL code to
- 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.
:todaycan 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 usertype: eithertemplateorview(see below)seachTerm: containing the unparsed or re-joined (see above) search term entered by the userscope: 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 spaceaccount: search items in the entire account / all "mounted" spaces
location: where a search was started, described as (only forviews):driveID: the space's drive ID (only forfolder,tree,drivescopes)path: the path inside the drive (only forfolder,treescopes)
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
searchTermandscope, but not thelocation. 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
Accountingspace, they could create a search view withscope = "drive", location.drive = "ae57q…", searchTerm = ":week :pdf".
Search expressions
A list of supported search expressions by the iOS app is part of https://github.com/owncloud/ios-app/pull/1142.
API proposal
An API could offer four endpoints:
add: for adding a saved search (based on the format outlined inPersistence)edit: for replacing a saved search with another one, based on the UUIDdelete: for deleting a saved search, identified by its UUIDlist: 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[bot]
Is your feature request related to a problem? Please describe.
ownCloud iOS app 12.0+ comes with a very fancy search feature:
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. (https://github.com/owncloud/web/issues/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
.searchfolder.Additional context
See screenshots and example search queries in https://github.com/owncloud/ios-app/pull/1142