API here is to be interpreted as an interface contract between the search engine and the rest of the system.

An API must be defined that can be applied to other Components (and other content, such as users who have decided to make their profile information public). The fields that can be indexed in order to perform the search should be indicated. This API will have to take into account whether a Component has been published or not.

Things to be defined:

Components (from #2593) and its weights:

• Home page
  • Global search searches in all fields of all components.
• Participatory spaces:
  • Assemblies. Proposed attributes: content: {hashtag: A, title: A, subtitle: B, short_description: C, description: D}.
  • Processes. Proposed attributes: content: {hashtag: A, title: A, subtitle: B, short_description: C, description: D}.
  • Initiatives. Proposed attributes: content: {hashtag: A, title: A, description: D}.
• User pages
  • Profile. Proposed attributes: content: {email: A, nickname: A, name: A}.
• Components:
  • Proposals. Proposed attributes: content: {title: A, body: D}, datetime: published_at
  • Meetings. Proposed attributes: content: {title: A, description: D, address: D}, datetime: start_time

How i18n will be managed?

Each Searchable will index one row for each Organization's supported locale. When Searchables are not translatable, they will still index its contents for each locale (same content in each locale).

pg_search strategy

Pg_search comes with 2 built in search strategies: multi-search vs search scope.

• Multi-search: automatic multi model search, but much less powerful. Compacts all search fields from models into one single column. No weights can be applied to columns.
• Search scope: powerful search parameters. To be implemented in each AR Model.

Strategies

There are many. Just throwing some ideas here in no particular order:

1. Go simple. Use multi-search and let Postgres' ranking do the job.
2. Sql view grouping all models with a union. This sql view will be queried with search scopes.
3. Use multi-search callbacks for custom indexing, but use search scopes for searching. I.e.:

• modify default pg_search_documents table to have 4 content columns
• [customize building of the documents in each Model]{https://github.com/Casecommons/pg_search#rebuilding-search-documents-for-a-given-class}.
• Do not use multi-search for searching. Instead create a SearchDocument model with a search scope.

4. Build our own multi search table, as multi-search does, and then use a model on this table with a search scope. (this is the same as the sql view strategy)

MVP

• add pg_search gem
• add search form in home page
• Ignore accents: used I18n.transliterate instead.
• Configure ranking/ordering
• Searchable models and its fields
  • Implicit filter by tenant.
  • Filtering by Model type
  • Filtering by scope
  • Apply localization (filtering results by locale or ignore locale on non i15d resources)
  • Searchable module
  • Apply Searchable to Resourceable?
• results:
  • proposal .card-result
  • meeting .card-result
• tests
  • Automatic indexation of Searchable models.
    • Meetings
    • Proposals
• Index already existing models when deploying for first time, so that they already appear in searches.