Skip to main content
Version: 2.x (upcoming)

Changelog

All notable changes to OpenCDMP and its services are documented here. Releases are grouped by platform version.

For upgrade instructions, see the Upgrade guide.

note

The Notification Service and Annotation Service are closed-source components distributed under a free license. Their changelogs are not included here.

v2.0.0 — Unreleased​

note

This release has not been tagged yet. The service versions below are provisional.

Service Versions​

ServiceVersion
API Service2.0.0
Webapp2.0.0
Notification Service0.0.23
Annotation Service0.0.25

API Service & Webapp​

New Features​

  • "Description" renamed to "Asset": The Description entity is now called Asset throughout the user interface — including Asset Templates (formerly Description Templates), Asset Types (formerly Description Template Types), Asset Statuses, and the My Assets / Public Assets pages. The term is localized in every supported language. Webapp routes changed accordingly, with the old /descriptions* URLs redirecting to /assets*. The API, plugin contracts, and data model retain the original Description naming.
  • "Organisation" and new role labels: The user interface says Organisation instead of Tenant, and the roles are relabelled: System Administrator (Admin), Installation Manager (InstallationAdmin), Signed-in User (User), Organisation Admin (TenantAdmin), Member (TenantUser), Template Manager (TenantPlanManager), and Content & Workflow Manager (TenantConfigManager). Role codes, permissions, routes, the API, and configuration keep the original naming.
  • Redesigned interface: A comprehensive UI redesign across the platform — the plan editor, asset editor, plan and asset overviews, listings, dashboard/home, navigation (sidebar and top bar), and the administrator content builders. The new plan and asset editors share a common layout with a table-of-contents navigator (numbered sections, previous/next navigation) and collapsible section panels. Required fields are clearly marked in both editors.
  • Admin menu and Settings hub: The admin menu is regrouped into Analytics (Research Insights), Templates (Plan Blueprints, Asset Templates, Types), Data Sources (Reference Types, Prefilling Sources), Organisation (Users, Settings), and Installation (Organisations, Quotas, Data Transfer, Maintenance, Edit Locks, Notification Log). Organisation > Settings gathers everything an organisation can adjust — branding, language and region, languages and texts, plugins, webhooks, plan and asset workflows, comment statuses, content defaults, help pages, notifications, notification templates, and users and onboarding — and shows each section only to the roles allowed to use it. Users, organisations, blueprint and asset template types (one Types page), plan and asset statuses (edited from the workflow diagram), help pages, notification templates, and reference entries are edited in drawers or single-page editors instead of separate listing and editor pages. /plan-statuses and /asset-statuses redirect to the workflows section. See Administering OpenCDMP.
  • Plan editor toolbar: The editor header is a single toolbar with the plan title, a status pill in the configured status colour, explicit Download, Evaluate, and Publish actions, icon buttons for Duplicate, Start a new version, and Delete, the Comments and Collaborators panels, and a Save button that saves and keeps the editor open, with Save & Close / Save & Continue in its menu. A "Change plan status" menu lists each target status with its icon and description, and an "unsaved changes" chip (a dot when the toolbar is crowded) replaces the previous editing banner. The Collaborators panel opens as an overlay side sheet, while Comments still docks beside the content.
  • "Add a new asset" wizard: Adding an asset from the plan editor is a three-step flow — choose how to fill it in (Fill in myself, Import from a published resource when the section enables prefilling, or Copy from an existing asset), pick a template from the section's linked templates (with an Overview side sheet), and name the asset. Copy candidates are filtered to the section's attached templates, and owners are guided to attach a template when a section has none. A permanent add-asset button is available in the table of contents.
  • Unified, atomic save: The plan editor uses a single save action with a clear dirty-state indicator; changes are persisted atomically, and plan status and lifecycle actions are consolidated in the editor's top action bar.
  • Two-step plan creation: Creating a plan is now an inline, full-page flow — select a blueprint (grouped by blueprint type, with search and a live blueprint preview), then create the plan. Importing a plan from a file moved into this blueprint-selection screen.
  • Plan version comparison: Any two versions of the same plan can be compared field by field from the plan overview (GET /api/plan/{id}/version-diff/{otherId}). System values (title, description, language, access rights, contacts, tags), blueprint fields, and asset fields are diffed, and assets are matched across versions through a server-owned provenance record (new additional_info column on Plan and Description). See Versions.
  • Redesigned plan blueprint and asset template editors: Blueprints and asset templates share one editor with Details, Structure, and Review tabs, replacing the previous stepper editors. The Structure tab has a numbered outline with drag and drop (Alt to copy), Move or copy to…, duplicate, and Insert from another template or blueprint; questions are added by input type, preset fields are added from a bar, and conditional rules read as sentences. One problems list drives the header, the problems panel, and a Finalise… checklist, and saving is blocked until problems are fixed. The Review tab previews the structure as authors meet it. Lock banners with Take over, Compare with vN for new versions, a version history page, and an Editors side panel for asset templates complete the editor. See Blueprints and Asset Templates.
  • Plan creation consent: A blueprint can require the user to accept a consent statement before a plan is created, cloned, or versioned. The consent text and details are configured per blueprint; the checkbox resets when the user switches blueprints. See Blueprints.
  • Terms and Conditions acceptance: Organisations can configure Terms and Conditions with an explicit version. Users must accept them on first login, and re-acceptance is required whenever the content or version changes. See Organisation settings.
  • Webhooks: Organisation Admins can subscribe external systems to plan and asset events (plan finalized, plan status changed, plan reverted to draft, plan deposited, asset finalized), send a test ping, and inspect deliveries. OpenCDMP sends a signed HTTP POST per event, retries failed deliveries with increasing delays, and keeps a delivery log with manual re-queue. Each webhook receives only the events of its own organisation, the default organisation included. The feature is enabled with WEBHOOKS_ENABLED and configured through the new webhook.yml (WEBHOOKS_* variables). New permissions: BrowseWebhookSubscription, EditWebhookSubscription, DeleteWebhookSubscription, ViewWebhooksPage. See Webhooks and the developer guide.
  • Research Insights (Analytics): A new Analytics administration group hosts Research Insights (/reports), which counts how a question of an asset template or plan blueprint was answered across the organisation, with filters, breakdowns, and CSV export. Semantic tags shared across templates are counted as a single cross-template question. System Administrators and Installation Managers can switch to Every organisation to count across the installation, with an Organisation breakdown and a higher item limit. Configured through the new report.yml (REPORT_* variables). New permissions: BrowseReport, ExportReport, ViewReportsPage, BrowseInstallationReport, ExportInstallationReport. See Answers and the report API.
  • Data Transfer: A new Data Transfer page (Installation group) lets administrators export the content of an organisation as a bundle, import a bundle into an organisation of another installation (additive, with a dry-run analysis first), copy selected content between organisations of the same installation, and purge the data owned by an organisation with a typed confirmation. Bundles are compared by database schema (Flyway) version. Annotations are included when ANNOTATION_SERVICE_URL is configured and the annotation service runs the matching release. New permissions: TransferTenantData, PurgeTenantData, ViewTenantTransferPage. See Data Transfer.
  • Guided tours: First-time visitors to the redesigned pages (My Plans, plan overview, plan editor, My Assets, asset overview, Dashboard, Start a new plan) get a short page-specific tour introducing the new look and the Asset rename; the Support menu offers Take a tour of this page to replay it. Organisation Admins can switch tours off in Settings > Users & onboarding. Seen state is stored per user and organisation in user settings.
  • Per-asset evaluation results: Evaluators can return one result per asset. Results are shown in tabs named after the asset, and a Not evaluated outcome is shown as a neutral status with the evaluator's reason. Assets can also be evaluated directly from the asset overview, with an evaluation history. Evaluation notifications now describe every result ({benchmarks} and {result} placeholders).
  • Export options and selective export: When the selected file transformer advertises user options, an options dialog opens before each export (select, toggle, colour, number, and text options; blank values keep stored preferences). Plans can be exported with a chosen subset of sections and assets when the transformer supports it. Uploaded DOCX export templates are validated by the transformer on upload and warnings are shown in the plugin settings.
  • Publishing to a repository redesigned: The deposit action is labeled Publish (and the export action Download), available on the plan overview and in the plan editor toolbar. Publish opens a menu of the repositories the user can publish to and those that already hold the plan; choosing one opens a three-step Publish to dialog (Account, Review, Published). Users publish under the organisation's account or their own (saved credentials, a sign-in pop-up, or a token typed in the dialog that can be saved to the profile); choosing their own account never falls back to the organisation's or the installation's token. The review lists the files that will be uploaded, lets users adjust the metadata the deposit service will send (with plugin-described widgets, persisted per plan and repository in the new DepositMetadata table), and blocks publishing until required values are filled in. See Deposit a Plan.
  • Per-organisation repository settings: On each repository's plugin page in Settings > Plugins, an organisation chooses which accounts users may publish under and which one is preselected, its own repository credentials, record defaults, which files are deposited (Files to deposit), and which review sections are hidden and which values are locked. An organisation that has saved no plugin settings follows the default organisation's, and a setting left empty takes the installation's value. Plugin secrets are stored encrypted, in organisation settings and in user profiles, and are never shown again. See Deposit Services.
  • Richer plugin configuration fields: Plugin configuration fields support Boolean, Select (with options), Color, and Number types in addition to text, for both administrator and user settings.
  • Redesigned profile page: The profile has four tabs (Profile, Language & region, Notifications, Repository accounts) with one save bar. Users choose which channel comes first per notification group, repository credentials are shown as a status list, and the header language switch saves to the profile. See Profile Settings.
  • "Editor" plan role: The plan role formerly named Description Contributor is now named Editor. Access is unchanged. In the invitation dialog, the collaborator type labels are now Existing collaborator (formerly Registered) and New collaborator (formerly External).
  • Asset template updates in a plan: When a newer version of an asset template used in a plan is available, users are prompted to update; a preview shows the field-level changes to accept or reset before applying.
  • New Number field type and inline preset fields: Asset templates and blueprints can include numeric (Number) questions and preset fields (system fields such as an asset's Title, Description, and Tags, or a plan's Title, Description, Language, Contact, and Access Rights) rendered inline in the form. Preset fields cannot be repeated; a plan's Title, Description, Language, and Access Rights and an asset's Title are always required.
  • Transposed table view: Multi-entry (multiplicity) questions can be displayed as a transposed table (fields shown as rows), in addition to the existing table view.
  • Blueprint and asset template icons: Blueprints and asset templates can be given an icon, shown in listings and selection screens. Icons are found by typing part of a Material icon name and picking from suggestions that show each icon, or uploaded as an image.
  • Redesigned reference type editor: Fields, Sources, Manual entries, and Entries tabs. Each API source is set up in steps (Request, Search rules, Test and map, Display), with a live test that shows the raw reply, click-to-map paths, and mapping previews that update as paths change. Fixed lists are edited as a table, and field changes update every source's mappings automatically. The Entries tab lists a type's entries with plan and asset usage counts and filters by origin and Used only. New endpoint POST /api/reference/test-source (requires EditReferenceType). See Reference Types.
  • Redesigned prefilling source editor: Connection, Search, Full record, Fill rules, and Try it tabs. Fill rules replace API fields and fixed value fields, and Try it previews the prefilled asset without saving. New endpoint POST /api/prefilling-source/test-source (requires TestPrefillingSource). See Prefilling Sources.
  • Reference source enhancements: Reference type external sources can display a logo, a navigation URL, and a tooltip in the redesigned reference picker, and can consume external sources that return XML in addition to JSON.
  • Manual references (#307): A reference added by hand gets a generated identifier and is never merged with another reference; editing one creates a new entry for that field only. Reference types can build the name of manual entries from their fields (name pattern, labelTemplate in the definition), and the add/edit dialog is redesigned. See References.
  • Language texts as overrides: Languages store only the texts an organisation changes, on top of the built-in texts, which keep receiving updates. A new text editor offers search, section and changed/not-translated filters, JSON import and export, added texts, and reset. Custom languages fall back to English. The default language comes from Language & region instead of the language order, and Override from file is gone. See Languages.
  • Comment editing: Users can edit and delete their own comments. The comments experience was redesigned with a "View all comments" side panel, author role chips, and clickable anchors that navigate to the referenced question.
  • New rich text editor: The rich text editor was replaced with a new implementation offering a Format / Plain Text toggle and a hideable toolbar; the editor opens in plain-text mode with the toolbar hidden.
  • Library pages: Users can browse available blueprints and asset templates from dedicated library pages, and a getting-started guide is surfaced from the dashboard.
  • Integration events: An optional integration event channel can be enabled with INTEGRATION_EVENT_ENABLED. See the backend configuration reference.
  • Semantic objects and answer keys: Sections and questions of blueprints and asset templates can name the object they describe (for example rda.dataset.distribution), so several plain questions export as one object instead of one object per answer. Select and radio options can stand for semantic key values (for example "Zenodo" sets the host title, URL, and PID system) or be marked Exports nothing. They are set in the Structure tab of the blueprint and asset template editors: This section is, a question's Export row, and Answers stand for keys. See Semantics.
  • Plugin semantics coverage: Plugins can publish the semantic keys they read. The blueprint and asset template editors use these manifests (GET /api/semantics/plugins) to suggest keys and objects. The Review tab shows one block per plugin with the needed values a structure covers (amber when the plugin writes a fallback, red when nothing fills the gap), the mappings that will not export correctly, and the values it could also use. In a blueprint, values filled by the attached asset templates count too. Nothing in it blocks saving or finalizing.
  • Automatic database migrations: The API service migrates its database with Flyway at startup, recording applied migrations in DBMigrationHistory. An empty database gets the full schema and seed data. Installations from 1.2 onwards upgrade in place, including databases built from seed scripts or patched by hand; older ones apply the db/ scripts up to 01.00.010 first. The 2.0 conversions of asset templates, blueprints, blueprint sections, and plan values run as migrations, and a definition that cannot be parsed stops the upgrade. See the Upgrade Guide.
  • Maintenance page redesign: Maintenance tasks run as server-side batches, one run at a time across the installation, with progress, stop, stop-on-failure, and per-task last-run state. A Full refresh preset runs everything, and a Database card shows the migration state and history. See Maintenance.

Improvements​

  • Export settings follow the switched-on plugins: the Export template card of blueprints and asset templates shows only the settings of export plugins the organisation has switched on, and is hidden when none is. Deposits no longer upload the plan document or the RDA JSON when the organisation has switched off the export plugin that produces it.
  • Asset template structure simplified: The template definition no longer has a separate "pages" layer; sections (which can nest) sit directly under the definition. Plan blueprints and asset templates now share a common section and field model. The user-facing grouping terminology (Section) is unchanged.
  • Prefilling on blueprint sections: A section that enables prefilling but lists no specific prefilling sources now offers every active source of the organisation; a non-empty list still restricts the choice to those sources.
  • Plan listing filters and views: Plans can be filtered by blueprint and by blueprint type from the filters side panel, and the listing offers Compact view and Full view layouts. Reference filters rank references by how often they are used.
  • Public plans and assets across organisations: Public Plans, Public Assets, their public overviews, and the anonymous Dashboard counts include public records of every organisation in the installation, from both the database and Elasticsearch.
  • Evaluation box visibility: The Evaluation box on the plan and asset overview is shown only to users who can evaluate, or when past results exist.
  • Plan import: A field that references an internal plan or asset missing from this installation now reports which id to remove (errors 197 and 198).
  • Settings inherited from the Default organisation: The Settings hub shows the value that applies to the organisation. Branding, Language & region, Content defaults, plugin settings, and guided tours that the organisation takes from the Default organisation are marked Set by the installation and shown read-only, with Use your own value to start the organisation's own copy; the Overview cards count them. An organisation without its own plan or asset workflow sees the Default organisation's workflow the same way, and GET /api/plan-workflow/current-tenant and /api/description-workflow/current-tenant return it. See How settings are saved.
  • Workflow enforced by the API: Plan and asset status changes that the organisation's workflow does not allow from the current status are refused (error 210), also for integrations. See Plan & asset workflows.
  • Safer role changes: In Users, the confirmation says when a change removes someone from an organisation or adds them to it, and an Organisation Admin removes a member by taking away all their organisation roles. Admins cannot take their own admin role away (error 199), an organisation keeps at least one Organisation Admin (error 209), and only a System Administrator can give or take away the System Administrator role, which the drawer locks for Installation Managers. People who have never signed in are marked Not signed in yet. See Users.
  • Status icons and account roles: In the status panel of Plan & asset workflows, a status can be given an icon (a Material icon or an uploaded image), shown in the plan and asset status menus of the plan editor, and Who can move a plan here lists every account role, not only Organisation Admins. See Plan & asset workflows.
  • Allowed status changes and shared statuses: On Plan & asset workflows, the moves allowed between statuses are ticked in an Allowed changes grid below the diagram (rows are the current status, columns the new one) and saved with the page's save bar, instead of in the status panel. In organisations other than the Default organisation, statuses shared by the Default organisation open read-only, without Save or Delete status: they can be edited only in the Default organisation. See Allowed changes and Statuses shared by the Default organisation.
  • Finalized plans keep their collaborators: The Share button is hidden on a finalized plan, and the API refuses to assign or invite collaborators to one (error 119), also when they are added through the plan's save call.
  • Notification templates: A customised notification cannot be saved without a subject and a message.
  • Workflows and plugin status: When no workflow exists, the workflow card says that new plans (or assets) cannot be created until one is saved, and the Default organisation's workflow, which the others fall back to, has no Reset to default. The Plugins page checks whether each plugin answers every time it is opened. See Plan & asset workflows and Plugins.
  • Publish review errors: When the repository does not return the review, the Publish to dialog shows Couldn't load the review with Try again and Back, instead of the publishing failure.
  • Usage per version: The blueprint and asset template editors and their version history count the plans or assets that use each version.
  • Swagger UI: The report endpoints are listed in the Current group. See Swagger.
  • Listings on small screens: Listings switch to a list layout on narrow viewports, and sorting by the actions column is disabled.
  • Semantics: New RDA affiliation semantics (rda.dmp.affiliation.name, rda.dmp.affiliation.affiliation_id, rda.dmp.affiliation.affiliation_id.identifier, rda.dmp.affiliation.affiliation_id.type) were added to the suggested semantics list.
  • Search syntax: Listing searches treat a term wrapped in double quotes as an exact match and support * and ? wildcards; other terms match anywhere in the text.
  • Elasticsearch index: The plan index now carries the plan blueprint (including its type) and the asset template index carries the asset type, backing the new blueprint and type filters. Run the Rebuild plan and asset indexes maintenance task after upgrading so existing records gain the new fields.
  • Upload limit: The multipart upload limit is 100 MB by default and configurable with MULTIPART_MAX_FILE_SIZE and MULTIPART_MAX_REQUEST_SIZE (previously fixed at 10 MB).
  • Administrator listings share one listing layout with Owned by / Shared by default organisation / All scope tabs, search, filter chips, a column picker, and density settings. See Admin Listings.
  • New plan-collaboration notifications: Plan Role Added, Plan Role Changed, Plan Role Removed, and Plan Access Removed.
  • External API fetcher in-memory buffer size increased to 50 MB for large reference source responses. Deposit plugin connections have a required Largest response (bytes) setting (6554000 by default).
  • Docker example: Starts with a single docker compose up -d on http://opencdmp.localhost:8180/, replacing deploy_opencdmp.sh. The API service builds the database, so the seed scripts were removed. Both Elasticsearch passwords are set in .env (ELASTIC_PASSWORD, and the new ELASTIC_API_PASSWORD for the API service's user) and config-files/elk/elk.env is gone; the Elasticsearch heap is 1 GB, half its memory limit; Keycloak uses KC_BOOTSTRAP_ADMIN_USERNAME and KC_BOOTSTRAP_ADMIN_PASSWORD; and the realm export gives its groups the expected roles. See Installation.
  • Audit event ids: Plan_GetPublicXml (now 5026), FileTransformer_ValidateTemplate (20002), and the Evaluation_* events (1100000–1100003) no longer reuse ids of other actions. See Audit events.
  • Accessibility: Contrast, labelling, focus indication, and keyboard access were fixed across the editor and the main pages.
  • Dependencies: The webapp moved to Angular 22 with standalone components and builds on Node 24, and uses jsPDF 4. Upgraded @swimlane/ngx-datatable to v24 and @dicebear/core to v9; removed the unused tslint, codelyzer, protractor, Karma, and ng2-dragula packages in favour of ESLint and Playwright.

Fixes​

  • User avatars were not displayed after the dicebear upgrade; a shared fallback avatar directive is now used everywhere.
  • Public assets were always disabled for cloning, and the asset type name was missing from the public asset query.
  • The search term in the "copy from an existing asset" box was transformed twice, and paging kept a stale offset after adding a search term.
  • Editing a plan after adding an asset to another plan could corrupt the form (#344); reference cards overflowed on the plan and asset overviews (#345); the asset template lookup used the wrong nested type (#347).
  • Console errors on the Notifications, Annotation Statuses, and Reference listing pages caused by mistyped enum helper names.
  • Links from listings led to 404 pages when the hybrid listing mode was "list"; row titles were missing in list mode.
  • A cross-tab reload loop and empty browser tab titles; comment mentions, tour anchoring, and asset limits in the plan editor; the deposit workflow and entity lock edge cases.
  • Asset evaluation notifications reach the members of the asset's plan and use the asset evaluation notification type.
  • Answers counted items of other organisations, and dashboard and library links lost the organisation prefix.
  • Save and delete buttons could be pressed again while their request was running (#91).
  • Webhooks of the default organisation received the events of every organisation, and the touch event maintenance tasks resent the default organisation's plans and assets with every organisation.
  • Saving a plan or asset without properties through the API failed with a server error instead of a validation error.
  • In the shipped Keycloak realm, Installation Managers were also System Administrators, Members of any organisation also joined the default organisation, and the Template Manager and Content & Workflow Manager groups of the default organisation gave no role.
  • Colour pickers did not open; success and error messages of file uploads, the plan contact field, and some plan editor dialogs were not shown; settings listings showed their results only after the next click.
  • Edit Locks linked to plans and assets of other organisations, which then could not be found; the user name in Users led to a missing page; the rows of the notifications page were broken.
  • Version history multiplied the usage counts of blueprints and templates; read-only choice questions showed no options.
  • When an organisation was created, Installation Managers were added to its Organisation Admin group in Keycloak although they became Members.
  • The Finalise this item? dialog showed its warnings only when an asset was already finalized; a too-many-answers error showed a text key instead of Please provide at most N answers; the theming link of Branding led to a missing page; undoing the finalization of a plan that was not finalized was not refused.
  • Public Assets searched through Elasticsearch also counted draft assets and assets of plans that were not finalized.
  • The Plugins card of the settings Overview and the Plugins page could disagree about which plugins were not responding.
  • A plugin address ending in / could not be reached; the blueprint preview's Download PDF failed.
  • Docker example: the evaluator address ended in /, help pages served the built-in texts instead of the mounted material folder, and rolled log files were written outside LOGGING_PATH.
  • The Download menu kept loading when no export service answered (it now offers XML); Delete was offered on published plans in the plan overview; Cancel in the plan editor asked for confirmation without changes; Create Plan Blueprint followed the wrong permission; the Organisations Usage action showed without the KPI service.
  • Importing a RAiD file failed for blueprints whose sections fix their asset templates, an RDA file with several assets on the same template of such a section was refused, and a plan whose templates did not match such a section was refused with a server error instead of error 178; an RDA file with several datasets on the same asset template added that template to its section more than once; the New Version and Copy Asset to Plan dialogs listed the blueprint sections without their names; saving a status from the workflow status panel failed; the icon field cleared an icon name saved earlier that is not among the Material icons.
  • Editing a comment dropped its mentions; replies showed the role chips of the thread's first author, including roles the person no longer had; role chips and @ mention suggestions included people removed from the plan; the comment count of the plan overview included deleted comments; long names and unbroken text widened the comment cards past the panel.
  • Leaving the plan editor could release the same edit lock twice and fail with a server error, and kept the lock taken after accepting a blueprint's creation consent; the Collaborators panel lost the email addresses of its rows after Send invite.

Removals​

  • Legacy Public API removed: The unauthenticated public API (/api/public/dmps/**, /api/public/datasets/**) and its configuration (public-api.yml and all PUBLIC_API_* variables) were removed.
  • Authors/Contributors blueprint field: The plan editor no longer renders the Authors/Contributors (plan user) field; collaborators are managed from the Collaborators panel. The 2.0 blueprint migration drops the field from migrated blueprints.
  • Maintenance data migrations: The data migration actions of the Maintenance page (Set canEditAssetTemplates to true and the 2.0 pre-release Migrate Pages / Migrate Fields as Asset Template / Migrate Fields as Asset) were removed, together with their endpoints and audit events. Database migrations replace them.
  • Previous editors: The previous blueprint, asset template, reference type, and prefilling source editors were removed, together with the unreachable blueprint and template import dialog and the listings' versions mode.

Plugin contract changes​

  • Evaluator plugins (evaluator-base): rankPlan and rankDescription now return a list of RankResultModel instead of a single result (breaking for plugins that implement the interface; wrap a single result in a one-element list). RankResultModel gains an optional target (EvaluationTargetModel with entityType, entityId, label) and SuccessStatus gains NotEvaluated. OpenCDMP validates targets against the evaluated plan and falls back to ordinal labels for untargeted or pre-2.0 results. See the evaluator plugin guide.
  • Plugin configuration (common-models): The configuration DataType gains Boolean, Select, Color, and Number, and ConfigurationField gains a label/value options list. Values are unchanged on the wire.
  • File transformers: Per-export options are delivered as user plugin-configuration values for the target transformer, and a transformer may expose a validate-template endpoint that OpenCDMP calls when an export template is uploaded. See the file transformer plugin guide.
  • Deposit plugins (repository-deposit-base): DepositConfiguration gains uploadedFiles (a DepositFileKind list: PlanDocument, RdaJson, SupportingFiles; empty means all) and oauthScope. The new DepositPluginSettings helper reads the organisation's plugin settings; the platform itself reads publish-ways, publish-preselected, organisation-account-name, and deposit-files. PreviewFieldGroup.required blocks publishing while a required repeatable group has no rows. With PluginDefault, plugins use the organisation's credential setting before the installation's token. authMethods replaces depositType, and the platform does not read accessToken. See the deposit plugin guide.
  • Semantic objects (common-models): SectionModel and FieldSetModel gain semantics (the objects they describe), and select and radio options gain semantics (a list of SemanticValueModel key/value pairs) and exportsNothing. All are optional and empty on existing structures. See Common Models.
  • Semantics manifest (common-models, file-transformer-base, repository-deposit-base, evaluator-base): New SemanticsManifest, SemanticKeyUsage, SemanticObject, and SemanticVocabulary models and the SemanticKeyLevel and SemanticValueFormat enums. FileTransformerConfiguration, DepositConfiguration, and EvaluatorConfiguration gain an optional semantics property. See Semantics Manifest Models.

Database and configuration changes​

  • Database migrations: The API service applies migrations itself at startup; do not run database scripts by hand from 1.2 onwards. DB_USER needs rights to create and alter tables. DBVersion stays at 01.01.009. New tables: DepositMetadata, WebhookSubscription, WebhookDelivery, MaintenanceRun, and MaintenanceTaskRun, plus the KPI service tables (skipped when they exist); new additional_info columns on Plan and Description. See the upgrade guide.
  • New configuration files: webhook.yml and report.yml are loaded by the API alongside the existing configuration files.
  • New environment variables: WEBHOOKS_*, REPORT_* (including REPORT_MAX_SUBJECTS_INSTALLATION), KPI_VIEWER_BOOTSTRAP_ENABLED, KPI_VIEWER_BOOTSTRAP_DELAY_SECONDS, ANNOTATION_SERVICE_URL, MULTIPART_MAX_FILE_SIZE, MULTIPART_MAX_REQUEST_SIZE. See the backend configuration reference and the upgrade guide.
  • No longer used: SUPPORTIVE_MATERIAL_LANGUAGE_PATH and the /i18n volume of the API container. Languages saved before 2.0 hold a full copy of the texts; open and save each customized language so that it keeps only its overrides.

File Transformer — Docx​

  • Template tags: Templates are written with {{…}} tags (loops, conditional blocks, formatted content), and the built-in templates are redesigned on them. Layout, references, cover facts, and wording are set through export settings. See Managing templates and Export settings.
  • '{OPENCDMP.…}' placeholders removed (breaking): Templates using the original placeholders are no longer rendered. Uploading one reports an error, and exports that would use one fall back to the built-in template. Recreate such templates from the built-in template; see Templates with '{OPENCDMP.…}' placeholders.

File Transformer — RDA maDMP​

  • Repository of the plan identifier: The setting's description refers to the Plugins page for the repository id.
  • Objects and answer keys: Sections and questions that name an RDA object group their answers into one object (for example one distribution with its host and one licence per answer), and answer options that stand for key values are exported as those values. An Exports nothing option leaves the object out. See the RDA semantics reference.
  • Semantics manifest: The transformer publishes the keys it reads, the RDA objects they make up, their formats and accepted values, and its fallbacks. Values RDA requires inside an object are marked as needed, so the editors show them where the structure uses the object.
  • Import: All ten official RDA DMP Common Standard examples now import, including properties given as a single object where the schema expects a list. Answer options are chosen by matching key values, plan-level objects are placed once, and a question that takes one answer keeps the first matching object.
  • Identifier types: Identifier types are written in lowercase as the RDA schema requires (other, orcid, doi, fundref). Missing types are inferred: orcid for an ORCID, doi for a DOI (plan and dataset identifiers), url for another web address, otherwise other.
  • Plan identifier: dmp_id can be answered through rda.dmp.dmp_id semantics; a minted DOI still comes first. On import, an OpenCDMP plan UUID is not written back.
  • Distributions: One distribution is written per picked repository, a distribution without a title takes its host's title, and empty distributions and creators are no longer written. issued and available_until are written as dates, and byte_size as a whole number.
  • Fewer duplicates: A reference picked in several blueprint fields is exported once, and the same project is not written twice.
  • Values: Yes/No inputs on keys that take yes, no, or unknown are exported as yes or no. dataset.rights no longer falls back to the asset title.

Deposit Services​

  • Authors from plan members: The option that credits owners and editors is labelled Owners and editors (Zenodo, Dataverse, DSpace, Fedora).
  • Zenodo: None is labelled None (users must add the creators in the review); the default publisher is Zenodo; an additional title with an empty type is sent with the type other; a plan without funders or grants no longer sends an empty funding entry.
  • Dataverse: Grant references are read, through the new Grants reference type setting (DEPOSIT_DATAVERSE_GRANTS_CODE, default grants): each grant becomes a grant number, with the plan's funder as the agency when it has only one. Related publications, grants, and contacts are no longer duplicated, a contact without a name is sent without one, the review keeps the identifier type, identifier, and URL of related publications, and a date of deposit edited in the review is sent as yyyy-MM-dd. The suggested semantics use the plugin's dataverse.publication.type.* and dataverse.publication.relation_type.* keys. See the Dataverse semantics reference.
  • CKAN: An extra answered in several places, for example in several assets, is sent once with its distinct answers joined by commas, so CKAN accepts the dataset.
  • DSpace: A public plan keeps its public page as the first dc.identifier.uri when dspace.identifier.uri is also answered.
  • DSpace, Fedora, CKAN: The semantics manifests and setting descriptions match what the plugins do: every DSpace record has the Default item type, with the plan's types added after it, and a CKAN organisation semantic must name a CKAN organization.

v1.3 — 2026-03-24​

Service Versions​

ServiceVersion
API Service1.3.0
Webapp1.3.0
File Transformer — Docx1.3.0
File Transformer — RDA maDMP1.3.0
File Transformer — RAiD1.3.0
Deposit Service — Zenodo1.3.0
Deposit Service — DSpace1.3.0
Deposit Service — CKAN1.3.0
Deposit Service — Dataverse1.3.0
Deposit Service — Fedora1.3.0
Evaluator — RDA maDMP1.3.0
Evaluator — OSTrails DMP Evaluation Service1.3.0

API Service & Webapp​

New Features​

  • Plan Blueprint Types: Administrators can categorize blueprints with types, enabling filtering and better organization across the blueprint library
  • Real-time collaboration: Active users shown live in the plan editor and plan overview; navigate to another user's position in the editor
  • Plan update requests: Users can request changes to a finalized plan; the plan owner receives a notification and can accept or reject the request
  • New plan role notifications: Email and in-app notifications sent when a user's plan role is added, changed, or removed
  • OSTrails evaluator: Full configuration and UI support for the OSTrails DMP evaluation service
  • OpenAIRE FAIR evaluator: Full configuration and UI support for the OpenAIRE FAIR assessment service
  • Evaluator benchmarks: Evaluators can return benchmark comparisons alongside rank results; benchmark IDs are configurable per evaluator
  • Tenant label translation: Tenant labels are now translatable per language
  • Enriched semantics: HealLink and RDA DMP Common Standard v1.2 semantic field definitions added
  • Reference type enhancements: Semantics support in the reference type editor; required field option; popup to view field details; fields included in export and import
  • Public page improvements: Plan authors shown on public pages; description preview added to public plan pages
  • Swagger UI: Extended API documentation with public plan and description endpoints; configurable via SWAGGER_ENABLED, SWAGGER_AUTH_REDIRECT_URL, and SWAGGER_SERVER_URL
  • Supporting zip file: Plans can now include a supporting zip archive of attachments
  • Cookie consent and analytics: Matomo analytics integration with per-user consent controls

Improvements​

  • Spring Boot 4.0.0 and Angular 21 upgrades; Material v20 UI and Keycloak v19 compatibility
  • Plan listing: DOIs column; references displayed using reference type configuration
  • Plan overview: status colour, reference labels, language name, and date format improvements; notification when a newer version is available
  • Blueprint editor: finalize button hidden when blueprint is in a new-version draft state

Fixes​

  • DOI messages and deposit dropdown display
  • Organization display in user profile

File Transformer — Docx​

  • Reference type field information now rendered in output documents
  • Font size in reference rows configurable via the DOCX template rather than hardcoded

File Transformer — RDA maDMP​

  • RDA DMP Common Standard v1.2 support
  • Full import coverage for project objects, contributors, contacts, and funding/grant identifiers

File Transformer — RAiD​

  • JSON export following the RAiD specification (v1.6–1.6.3)
  • Identifier, access, and date semantics supported for description template export

Deposit Service — Zenodo​

  • Reference type semantics for researchers and licenses mapped to Zenodo metadata
  • New version deposit: previous DOI stored as parent record

Deposit Service — DSpace​

  • DSpace 8.x support with username/password authentication

Deposit Service — CKAN​

  • CKAN 2.11.4 support with access token authentication

Deposit Service — Dataverse​

  • Dataverse 6.9 support with access token authentication

Deposit Service — Fedora​

  • Fedora 6.x support with username/password authentication

Evaluator — RDA maDMP​

  • RDA DMP Common Standard v1.2 schema validation
  • Benchmark configuration and result fields

Evaluator — OSTrails​

  • Evaluates whether a plan or description aligns with the OSTrails metadata and policy framework
  • Assesses completeness, openness, and reproducibility against OSTrails guidelines

Evaluator — OpenAIRE FAIR​

  • Assesses whether a plan meets FAIR principles (Findable, Accessible, Interoperable, Reusable)
  • Provides structured feedback for improving FAIR compliance

v1.2 — 2025​

Service Versions​

ServiceVersionReleased
API Service1.2.22026-01-13
Webapp1.2.22026-01-13
File Transformer — Docx1.2.12026-01-05
File Transformer — RDA maDMP1.2.12026-01-07
Deposit Service — Zenodo1.2.22026-01-05
Evaluator — RDA maDMP1.2.02025-07-11

Patch Releases​

VersionReleasedChanges
API 1.2.12025-10-02Minor fixes and improvements
API 1.2.22026-01-13Deployment health checks, monitoring endpoint, external fetcher SSL option, bug fixes

API Service & Webapp​

New Features​

  • Custom DOCX templates: Upload a .docx template to a blueprint or description template to override the default export layout for plans and descriptions
  • Plan deposit overhaul: New deposit dialog with support for multiple authentication methods — system token, OAuth2, and user profile API key
  • Plugin user API key: Users can configure per-plugin credentials in their profile settings
  • Public plan pages: Public-facing plan and description overview pages for anonymous users, including access type visibility controls
  • Plan author ordering: Authors can be given an ordinal position within a plan
  • Reference type semantic fields: Semantic identifiers added to reference type fields; included in XML export and import
  • Blueprint description template restrictions: Controls whether plan users may edit attached description templates
  • New plan user roles: Data Privacy Officer and additional collaboration roles added
  • Description field set table view: Multiplicity inputs can be displayed in a table layout
  • Annotation indication in table of contents: Annotation counts shown at section and description level

Improvements​

  • Plan listing: DOIs column added; references displayed using reference type configuration
  • Plan overview: status colour, reference labels, language name, and date format improvements; notification when a newer plan version is available
  • Elasticsearch TLS certificate configuration support

Fixes​

  • Description field value saving for plan and description reference field types

File Transformer — Docx​

  • Custom DOCX templates: Dynamic replacement of template codes ({OPENCDMP.PLAN.*}, {OPENCDMP.DESCRIPTION.*}, {OPENCDMP.PLAN-REFERENCE.*}, {OPENCDMP.DESCRIPTION-REFERENCE.*})
  • Reference type code substitution in templates (e.g., {OPENCDMP.PLAN-REFERENCE.GRANTS})
  • Description section code, header and footer options
  • Upload field (file attachment) support in plan and description export

File Transformer — RDA maDMP​

  • Full import support for RDA DMP project objects, contributor semantics, and funding/grant identifiers
  • DMP contacts semantics applied on import

Deposit Service — Zenodo​

  • Communities support: Deposit to a specific Zenodo community
  • Software and conference semantics: Additional deposit metadata mapped from semantic fields
  • Custom fields and additional titles: Extended metadata support for Zenodo records
  • Funding and grant information populated from reference semantics
  • Access rights, custom license, and relator type support
  • New version deposit: previous DOI stored as parent record

Evaluator — RDA maDMP​

  • Benchmark support: Evaluator now returns benchmark data alongside rank results; benchmark IDs configurable

v1.1 — 2025-03​

Service Versions​

ServiceVersionReleased
API Service1.1.02025-03-26
Webapp1.1.02025-03-26
File Transformer — Docx1.1.02025-03-06
File Transformer — RDA maDMP1.1.02025-03-06
Deposit Service — Zenodo1.1.02025-03-06
Evaluator base library1.1.02025-03-05

API Service & Webapp​

  • Plan and Description statuses: Custom status workflows with colour indicators applied to plan and description overview pages
  • Material 3 design system: Full UI overhaul — cohesive M3 theming, consistent font sizing across the application, CSS cleanup
  • Accessibility improvements: Required field hints, ARIA fixes, toggle switch and guided tour improvements
  • Elasticsearch TLS: Certificate-based connection support
  • Inactive plan user display in plan editor improved
  • Plan and description action toolbar reorganised

File Transformer — Docx​

  • Dynamic template code replacement: Plan and description codes ({OPENCDMP.PLAN.*}, {OPENCDMP.DESCRIPTION.*}) replaced at export time; footer reference type codes supported
  • Description section code, header options
  • Language lookup from configuration file

File Transformer — RDA maDMP​

  • RDA project date format fix

Deposit Service — Zenodo​

  • Minor maintenance updates

v1.0 — 2024-10​

Service Versions​

ServiceVersionReleased
API Service1.0.02024-10-15
Webapp1.0.02024-10-15
File Transformer — Docx1.0.02024-10-11
File Transformer — RDA maDMP1.0.02024-10-11
Deposit Service — Zenodo1.0.02024-10-30

Patch Releases​

VersionReleasedChanges
API 1.0.12024-10-29Unlink account fixes, email expiration configuration, minor UI fixes
API 1.0.22024-11-21Reference label/quote fixes, content disposition fix, user credential change event, DB schema update

API Service & Webapp​

  • Initial public release
  • Plan and description creation, editing, versioning, and export
  • Blueprint-based plan structure with sections and fields
  • Description Template system
  • Keycloak OAuth2/OIDC authentication
  • Role-based access control (Viewer, Contributor, Reviewer) at plan and section level
  • Annotation and review system with comment statuses
  • Email and in-app notifications

File Transformer — Docx​

  • Initial release: Word and PDF export for plans and descriptions

File Transformer — RDA maDMP​

  • Initial release: JSON export following the RDA DMP Common Standard

Deposit Service — Zenodo​

  • Initial release: plan deposit to Zenodo with DOI assignment