We want search to be context aware, i.e. if you are inside a forum inside a course and you search for 'fish' the results should prioritize results with fish from inside that forum first, and then inside the other sibling forums, then the section, then course, then your other courses, then site level stuff.

Essentially using the context id hierarchy in Moodle to determine how 'far' we are from the content.

This isn't a new type of filtering, it's really just an alternate form of sort order, ie instead of using just pure relevance to the search terms it's order based on both relevance and proximity. Almost all engines internally support various concepts of different sort orders, so we would want this implemented generically at the engine api level and then each engine can declare whether it supports any additional sort orders.

A rough outline of what we think an approach could be:

• add a new method to the engine base class supports_sort_orders() which returns an array of supported sort orders. It would be a map of orders to the lang pack key. There would be a couple defined options like SORT_ORDER_RELEVANCE and SORT_ORDER_CONTEXT  The base would only return 'relevance'.
• An engine could choose to return as many sort orders as it wished, ie it could return those two core ones as well as 'last mod date', 'filesize' or whatever
• if the engine selected supports CONTEXT then in the quick search form in the header then an extra hidden field containing the current pages context hierarchy would be stored. Upon submission this is passed back to the engine. There would be a 'sort by' field form clearly showing that this is ordered by context and which can be changed back to raw relevance.
• If you go directly to the global search page then you will default to the relevance based search. If there are other alternate orders available (besides context) then the sort order field will also be shown. However context search is a special case and you can't simply swap from relevance back to context without providing a context. So in this case context would not be available in the sort order field
• the engine execute_query() would have an additional argument for the sort order.
• The core solr engine should implement at least one, but ideally both, other sort orders as a proof of concept. https://wiki.apache.org/solr/CommonQueryParameters#sort

It would be up to engine to choose how to balance the relevance and proximity together, this could either be hard coded into each engine or it could provide admin settings to allow tuning of the boost levels.

See UI rough mockup below

The preselected option would depend on how you searched:

• Relevance would be shown if you searched from the site dashboard or navigated directly to the global search page
• Contextual would be selected if you searched from a site subpage, e.g. a forum
• Most recent would always need to be selected by the user

We would also display the context the user is searching in below the global search heading, as shown in mock up

Additionally, maybe need to be some admin setting for how strongly we weight this stuff, for instance we could say that a site level support activity has a bit more weight or whatever

The very broad tasks that need to be done here are:

• Have search boxes in Moodle pass the context they were invoked in when they pass the search terms - core change
• Construct a context hierarchy with weightings (boost values) - core change, search plugins can override
• Search "types" - core to define, plugins to override with ones they support
• Alter and construct the search queries that go to the search engine backends to reflect the chosen sort types - search plugins