Filters (stored queries) is a new feature as of Tiki13 being in trunk

Its purpose is to store search criteria so that you are able to run search queries without enter search criteria again and again.

Feature is under construction, this page is meant to collect and evaluate related ideas.


Feature name

The current name of the feature (Stored Queries) too technical, how about calling the feature Filters? I think Filters is more user friendly, easy to grasp, to reference it, talk about it, etc.

Priority setting

gezza: Priority dropdown is a bit strange. Only one option (On Demand) is visible, but I think this option is not necessary, it can be removed (it is the basic state, that you can revisit any filter, no need for an option for this). The second and third options (if they get enabled again) should be checkboxes and not alternates.

LP: There are actually two other priorities that work when using elastic search as the engine. They use the percolator feature to trigger actions on save, such as direct email or adding the document to the watchlist.
The last part is still half finished. Adjustments for actions on save are very likely to be required.

Same name for different filters

Save allows to have the same name for two different queries, which is not good (I think filter name combined with userId should be unique)
LP: True.
gezza: tested, it is ok now, thanks

Label and Description

Label: rename to Filter Name and it would be useful to have a varchar field for description (Filter Description)


gezza: description added, thanks


gezza: I think there is no need for having tabs when editing an existing filter, show only the results. Edit and delete action buttons should be in the table listing filters. By pressing them the same window as when creating a new filter could come up in a bootstrap modal (

LP: That would not be a very hard change. However, I know it's a convention, but I usually find the delete button dangerously close to other actions.


gezza: modals added, very nice, thanks

Query review

gezza: When reviewing existing filters, it would be useful to see the query itself. Now I can see the name (label), last modification date and the results (if any), but I dont see what the filter is searching on. In the database it is also stored as binary. Imho there are two options: show as it was entered into the search field (simple view) or show as an SQL query (advanced view). In both cases, allow to modify and also to save the modifications or save as a new filter.

LP: That's technically very hard as the query can be stored from multiple locations, including custom search, and the internal representation is stored rather than the user input. This is actually an intentional design decision to match requirements.
Describing the query's intent from the internal structure is quite complex. It's a larger problem to tackle than the entire feature.
As for displaying the SQL, it does not always apply as most engines do not use SQL at all, and the query generated is not very readable for humans, especially if categories or other attributes are involved.

gezza: Ok, I understand that having multiple search engines it is not easy to retrieve the intent of a query. Still, I think it is important to show what the user is searching on when running an existing query. Otherwise knowing what the query is doing is only about giving a "good" name and a "good" description to the filter, which is too user skill dependent.
The information about what the query is searching on is already queried back somehow as it is used for highlighting search results. When highlighting is being done, there must be a step where the search results are compared with the saved query. Would it be possible to "catch" the information used for highlighting without running the query itself? I assume in the queries some items are texts (eg a word in a wiki page), some are ID-s (eg category IDs), so not everything is human readable, but it could be improved by matching for example the categoryid to the name of the category and showing the category name to the user.

LP: I'm not debating the usefulness. It is technically possible to introspect the query and figure out what it is. However, it requires a fair amount to do so, which is more than I have allocated on this specific project for the moment. A lot of parameters can go into the query. A lot more than just keywords. It's a complete tree of conditions. Just displaying it in a readable manner is challenging.


Filters are private by default, which is ok, but it would be handy to have a Share button, using which you can share your filter with user or a group. People can see the filters shared with them and select any to add it to their list of favorite filters if they want to.

LP: One of the early interface actually allowed for sharing. There is nothing to prevent it as permission filters are applied only when retrieving the query. It's just a matter of adding suitable UI for it.

  • if sharing is ok, than the owner of a filter should be displayed in the list of filters

LP: I was thinking more of as a link or bound with the activity stream, or other sharing mechanisms then building this custom for this feature.

Permanent name

filters could have a permanent name so that they can be used programatically (move among systems, deploy through profiles, etc)

LP: Good idea, although I would make it optional as the feature is more of a user feature than an administrator one.
gezza: optional sounds fine


later subscriptions could be added to filters (eg: send me and to some usergroups the results of a filter every friday at noon), but that is the area of notifications, so it is really just a footnote

LP: Quite related in fact. Notifications are the next item on my list and priorities are likely to be involved in this.