-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
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.
Metadata
Metadata
Assignees
Type
Projects
Status
To refine 🧚