Changelog

August 27, 2026

Extensions get first-class rows in the work timeline

A new API that lets Curvenote SCMS extensions contribute their own rows to the work-version timeline. Alongside it, deployers get a real hand on dashboard task layout, and Curvenote-hosted sites open on the submissions listing with a refreshed submission details page.

Curvenote SCMS

Extensions get first-class rows in the work timeline. Curvenote SCMS extensions can now register ExtensionTimelineItem descriptors and have them rendered alongside the built-in kinds on the work-version timeline.

Deployers control dashboard task sections, and Check My Work carries a NEW badge. The dashboard now takes a dashboard.tasks.sections config: each section names a heading, a set of task categories to include, and an optional ordered list of task ids to pin. Unlisted eligible tasks append after in alphabetical order. Task ids come from each extension’s task definitions and from any built-in tasks the deployer opts in. On the dashboard itself, the Check My Work task card now carries a small green NEW badge in its top-right corner, so operators can flag freshly added tasks to their contributors at a glance.

A deployer-configured task section on the dashboard: the heading, which tasks appear, and their order all come from config, and recently added cards carry a green NEW badge.

Figure 1:A deployer-configured task section on the dashboard: the heading, which tasks appear, and their order all come from config, and recently added cards carry a green NEW badge.

Curvenote Sites

Sites open on the submissions listing. Visitors landing on a Curvenote-hosted site are now taken straight to the submissions listing instead of the older inbox placeholder, so the first click already shows the site’s queue.

A refreshed site-admin submission details page. The submission details page opens with a scannable summary card — title, authors, description, DOI, published date — replacing the older social-media card. Collection, kind, slug, and publication-date edits move out of ad-hoc popovers into confirmable dialogs behind a shared editor shell, so accidental attribute or slug changes are caught before they land. Kind editing now stays safe when the current collection is missing, and the details card carries an inline status banner for the submission’s state.

The refreshed submission details page leads with a scannable summary card and an inline status banner, then lists the editable attributes — publication date, collection, kind, slug, and DOI — each behind a confirmable dialog, with the version timeline underneath.

Figure 2:The refreshed submission details page leads with a scannable summary card and an inline status banner, then lists the editable attributes — publication date, collection, kind, slug, and DOI — each behind a confirmable dialog, with the version timeline underneath.