Move Projects Service into Biblio Backoffice

[netsensei]

Epic

We would like to move the projects service functionality into Biblio Backoffice instead of keeping it a standalone service.

Rationale:

• No more need to keep a dedicated REST API for projects, and integrate with said API from backoffice.
• No more need to maintain a separate service (deployments, maintenance, configuration, etc.)
• Provide a starting point for projects to (potentially) become first class citizens within the Biblio Backoffice application.

Success criteria

• It's possible to upsert projects via a Benthos pipeline through a REST API endpoint via a dedicated add-project call.
• A researcher / curator is able to use the "Search Projects" box: searching for projects.
• A researcher / curator is able to link a project to one or more publications / datasets.
• A researcher / curator can see project details for linked projects on publication / dataset detail page.
• When searching for an author/editor/contributor/promotor/... I get feedback when typing 1 letter (see screenshots in comment)

Implementation suggestion

• Needs a dedicated OpenAPI endpoint via Ogen w/ dedicated registered routes.
• Needs a dedicated ElasticSearch index with re-indexing via River
• Move over repository code from the projects service and integrate in Biblio backoffice
• Do not use a dedicated projects_identifiers table (merge into projects table)
• Projects repo methods directly in the projects backend in backoffice.

Goal: for now, it's a semi-isolated service within the backoffice monolith.

[netsensei]

To Do

• Pipelines
  • Organization / People import: Error on Duplicate
  • LDAP set affiliation based on object class
  • LDAP pipeline deploy to nomad
  • Reindex jobs deploy to nomad
  • Handle Reindex in development
  • Auto-expire of persons
  • No benthos retry on 409
• Devcontainer
  • Seed for people & organizations
• Projects
  • Search & Get projects via OpenAPI
  • GetByIdentifier via Index
  • Trigger reindex API call
• People
  • GetByIdentifier via Index
  • Trigger reindex API call
  • Replace Affiliations in AddPerson
• Organizations
  • GetByIdentifier via Index
  • Add ceasedOn
  • Trigger reindex API call
  • Make siblings ordered
• Split off admin / inspection API calls in separate service No longer needed, the dict load balancer can do for us
• Frontoffice
  • Get user from repo not index
  • Replace all calls to "authority store" in biblio frontoffice with "API backoffice" calls.
  • Add people & project API calls to frontoffice handler
  • Solution for person publication_count
  • Solution for project publication_count
  • Solution for person settings (see frontoffice model)
  • Solution for orcid settings (send-emails), orcid bio, orcid id and token (see frontoffice model)
  • Solution for preferred name (see frontoffice model)
  • Solution for orcid.csv export

See https://github.ugent.be/Universiteitsbibliotheek/biblio/tree/issue-1380.

[mietcls]

Unexpected behaviour when looking for authors

Expected behaviour

[nicolasfranck]

Notes:

• since a more recent PR https://github.ugent.be/Universiteitsbibliotheek/biblio/pull/158 (in order to fix User IDs mixed up: back- and front office issues #1406), we decided to add a new attribute called best_ugent_id that contains more relevant ugent-ids to match on during lookups, as ugent-id's are often recycled, and we end with the wrong user. When I tried to merge in the master branch in this branch, I saw that helper method find_by_id was completely removed, and replaced by calls to Biblio::Backoffice#get_person. So .. create something similar in the backoffice?
• For the biblio frontend route /person, what should be do with people whose last name does not start with a letter. e.g. 'S HeerenDiane (http://localhost:9200/biblio_backoffice_people/_search?sort=sortName:asc). In the old implementation this is also a problem. Anyway that sortName needs some preprocessing (neither Elasticsearch nor Solr accept tokenized fields for sorting). I would suggest to do more preprocessing before assigning the nameKey (e.g. H for 'S HeerenDiane?). I see in ldap that the s from 's is used in the email address and username.
• @mietcls I see that the old suggest for projects returns more results. @nics the new setup copies all names and descriptions to be searched on to an ngrams, and removes extra queries on other fields, but those ngrams only start at two letters.

P.S. Feel free to move these notes somewhere else. I just need a place to put these

[nics]

🚧 🚧 On hold, see #1595 🚧 🚧

Last commit before revert: https://github.com/ugent-library/biblio-backoffice/tree/people_projects