Repository customizations

Overview

NRP (National Repository Platform) builds upon InvenioRDM  software and extends it to support repositories with completely custom metadata models, deposit forms, and record detail pages — all within a shared platform.

While InvenioRDM provides a unified data model and theming layer, NRP allows each repository to define its own metadata schema and corresponding frontend components that render, edit, and validate metadata in a tailored way.

This section explains how the customization layers fit together and what NRP-specific customizations are available to you.

Customization Hierarchy

InvenioRDM defines a clear instance-scoped customization hierarchy that determines how configuration, templates, translations, and assets are resolved at runtime. NRP repositories inherit this model. The key idea is that your repository project instance is the top-most layer that can override most defaults provided by upstream packages and modules.

The hierarchy flows from most specific to least specific:

1. Instance configuration and assets — anything defined inside your repository project (configuration values, /assets, /templates, translations, /ui) could override lower-level layer defaults.
2. Extension packages — themes or modules you install (such as oarepo-theme or other NRP packages) provide defaults that can be extended or overridden by your instance.
3. InvenioRDM and Invenio base packages — the final fallback layer containing core templates, translations, and theme variables.

Because all customization is resolved through this layered approach, you can safely override text, branding, messages, or templates at the instance level without modifying upstream code. This ensures a clean separation between your repository’s identity and the shared platform code.

For the original reference, see the InvenioRDM documentation:
InvenioRDM Customization Hierarchy .

InvenioRDM foundations

InvenioRDM provides a solid theming and customization system including:

On the backend side

• Flask app Configuration
  Easiest way to change settings like site name, default language, feature toggles, or more complex things like changing service or REST API resource implementation (where allowed), is to set exposed Flask app config variables of Invenio app and modules.

• Python package entry points
  Each InvenioRDM module is implemented as a Python package that can provide its own:

  • REST API resources
  • Database models
  • Background tasks

  One can leverage this mechanism to override existing functionality or provide new functionality by creating own Python packages and registering own package entry points.

These backend mechanisms form the foundation for InvenioRDM’s flexibility — and they continue to apply directly in NRP, where repositories build on them to implement repository and record model extensions.

On the frontend side:

• Theming and look & feel:
  Override or create static assets, LESS/CSS styles. Backed by Semantic UI theming system. See the InvenioRDM Look and Feel Customization  for more.

• JS components and asset pipeline:
  React-based UI components & mini-apps used for rendering interactive elements & pages like record deposition, search. Organized into Webpack “bundles” & built via Rspack. All bundles automatically discovered using Python package’s entry points and collected into a single repository-level Rspack project. Furthermore some default UI components can be overriden using the React-Overridable  mechanism.

• Templating and asset pipeline:
  Each Python package can provide its own server-rendered Jinja templates and static files, or override some other package’s templates and static files. Automatically discovered using package’s entry points and Flask templating mechanisms. More on this in the RDM Templating  docs.

These foundations apply equally to NRP repositories.

What NRP adds

Here is an introduction to NRP-specific concepts and customization layers on top of InvenioRDM.

CCMM (Czech Core Metadata Model)

NRP introduces the CCMM (Czech Core Metadata Model) as a flexible metadata schema that repositories can adopt or extend. This schema serves as an alternative to RDM record schema, as a starting point for defining the structure of records in NRP repositories.

Multiple record models

For InvenioRDM, there is a single pre-defined metadata model (RDM record schema) that applies to all records, with only limited customization options (e.g. adding a few simple extra custom fields to the model).

In NRP, each repository can define one or more record models — each with its own:

1. Metadata schema
   Specifies the structure of records as stored in the repository. Create a completely custom one, or build on top of pre-defined schemas like the CCMM or RDM record schema.
2. Serialization & validation From the metadata schema, NRP generates a corresponding Marshmallow schema that handles serialization, deserialization, and validation of records in the backend APIs.
3. Import & export formats
   Importers and exporters from/to other metadata formats (e.g. JSON, XML, BibTeX), based on the schema.
4. UI representation How model records are displayed and edited throughout the frontend application.

Every aspect of the record model implementation could be customized in greater or lesser extent, depending on the repository’s needs. Tooling is provided to make it easy to define & generate new record model packages, or extend existing models like the ones for CCMM or RDM schema.

Record submission workflows

InvenioRDM provides a basic record submission and approval workflow out of the box, applied to all submitted records, and there’s not much possibility customize it. In NRP, each repository can define its own more complex record submission workflows, on a per user community basis, that govern how records are submitted, reviewed, and published.

Custom Vocabularies

InvenioRDM provides a set of pre-defined controlled vocabularies (e.g. for resource types, languages, licenses) that are shared across all records. Vocabulary item schema is rather fixed and there’s no possibility to extend it with custom fields. Also there’s no UI for managing vocabulary items once the repository is deployed and vocabulary fixtures are loaded. Only a simple hierarchy of type/subtype relationships is supported for some vocabulary types (resource type).

In NRP, each repository can define its own custom controlled vocabularies, with possibility to extend the vocabulary item schema with custom vocabulary fields. You can also use complex hierarchies of vocabulary items (parent-child relationships). UI for managing vocabulary items directly in the repository frontend is provided to privileged users.

What’s next

The following sections will guide you through various customization options available to you in NRP-based repositories. For a detailed reference on InvenioRDM base, please consult the official InvenioRDM customization documentation  There are two major levels of customizations available:

Repository-level Customizations

These affect global behavior, look and feel, branding, and theming across the repository.

Model-level Customizations

These customizations are specific to a repository’s record models. They affect pages and components related to records, search results, and forms.