Repository: openfun/richie

Issue:
On the search page, the "more options" feature is broken on the "contributors" filter
## Bug Report

**Problematic behavior/code**
The "more options" feature on the "contributors" filter on the search page is broken.

**Expected Behavior**
When we click on "more options" on the "contributors" filter on the search page, we expect to see a list of more contributors and be able to type a search request to refine the search and find a specific contributor by his/her first/lastname.

**Steps to Reproduce**
1. Go to the search page: https://www.fun-mooc.fr/en/courses/
2. Click "more options" on the "contributors" filter

**Environment**
- Richie version: 2.5.0
- Platform: docker





Discussion:
This is a settings related issue.

The "Contributors" filter has `"contributors"` as a machine name (`"name"` in settings), where it should instead have `"persons"`.

There is no error because unrecognized names for endpoints fall into a catchall for categories, designed to support multiple orthogonal categories in a way that is transparent for the frontend.

There's no bug in richie, it is a fun-mooc issue; I'll have to let someone with access to fun-mooc settings implement the fix there.


Nice catch! 
But is there a design issue in richie because we were able to rename this filter "name" and the filter still works but the autocomplete is broken... Does it mean that this "name" can in fact not be changed? If yes then we'd better remove it from available settings?
In fact, I just checked and both the search filter modal and the autocomplete at the top both do not work for contributors. Filtering on the other hand works because the contributors are indexed in ES under the same name that comes from the settings, and determines the API route called by the frontend, and the filtered queries.

Right now `"persons"` and `"organizations"` are [special values for filter names](https://github.com/openfun/richie/blob/master/src/richie/apps/search/urls.py#L19). This means as you build  [your settings objects](https://github.com/openfun/richie/blob/master/src/richie/apps/search/defaults.py#L130), these are not names that can be changed but special names that link the filter being defined with a special category of filter.

I see three options:

1. Keep things as they are, update the `fun-mooc` settings.
2. Refactor the search code to make sure those names are parameterized everywhere, which might or might not mean folding their viewsets into the `CategoryViewSet`
3. Just make persons and organizations actually be categories

IMO we need to do 1/ now to fix fun-mooc.

Then we can work on 2/ or 3/ or just leave things as they are, depending on the level of effort and practicality to remove our special values (which might need a breaking change to settings).
So I did 1/. 
As for 2/ or 3/, let's do this when we refactor indexing to remove the "MPTree bird path" as id (which changes each time a page is moved in the page tree... which breaks indexing) and use database ids (that never change).

Resolving patch:
diff --git a/src/richie/apps/search/defaults.py b/src/richie/apps/search/defaults.py
--- a/src/richie/apps/search/defaults.py
+++ b/src/richie/apps/search/defaults.py
@@ -118,6 +118,8 @@
             "is_autocompletable": True,
             "is_searchable": True,
             "min_doc_count": 0,
+            # Note: this is a special name that connects the filter to Organization objects
+            # in Richie as well was the corresponding indexer and API endpoint.
             "name": "organizations",
             "position": 4,
             "reverse_id": "organizations",
@@ -130,6 +132,8 @@
             "is_autocompletable": True,
             "is_searchable": True,
             "min_doc_count": 0,
+            # Note: this is a special name that connects the filter to Person objects
+            # in Richie as well was the corresponding indexer and API endpoint.
             "name": "persons",
             "position": 5,
             "reverse_id": "persons",


Test patch: