You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two places currently hardcode the same workflow-state → color mapping independently:
packages/contents/components/ReviewState.tsx (the state dot in the @@contents listing)
packages/cmsui/components/History/HistoryView.tsx (statusDotClass, the "Action done" dot in the @@history view, added in [CMSUI] - History route #30 — deliberately mirroring the Contents mapping for visual consistency; marked with a TODO)
Both map published → --color-quanta-cobalt, private → --color-quanta-rose, versioning/green → --color-quanta-neon, and fall back to the neutral --color-quanta-pigeon for everything else.
This has two limitations:
Custom workflows: sites with their own workflows (other review states) only ever get the neutral fallback color. There is no way to register colors for additional states.
Theming: themes can re-color the dots only by overriding the Quanta token values globally. The mapping itself (which state gets which token) is not configurable.
Prior art
Volto solves this with a central, configurable mapping: config/Workflows.js → config.settings.workflowMapping, consumed by all components that render workflow states.
Proposal (to be discussed)
A single source of truth for the mapping, registered through @plone/registry (e.g. config.settings), with the current four entries as the default.
Values are design tokens (CSS custom properties), not hex values, so themes keep working.
A small shared component/helper consumed by both @plone/contents and @plone/cmsui. Open question: which package may host it so that both can depend on it (@plone/layout? @plone/components would need to stay free of Plone-specific logic per the conventions).
Acceptance criteria
Given a custom workflow state and a registered color for it, when the Contents listing or the History view renders that state, then the registered color is shown.
Given no registered color for a state, then the neutral fallback is shown (current behavior).
Contents and History render identical colors for identical states from the same source (no duplicated mapping).
Problem
Two places currently hardcode the same workflow-state → color mapping independently:
packages/contents/components/ReviewState.tsx(the state dot in the@@contentslisting)packages/cmsui/components/History/HistoryView.tsx(statusDotClass, the "Action done" dot in the@@historyview, added in [CMSUI] - History route #30 — deliberately mirroring the Contents mapping for visual consistency; marked with a TODO)Both map
published→--color-quanta-cobalt,private→--color-quanta-rose, versioning/green →--color-quanta-neon, and fall back to the neutral--color-quanta-pigeonfor everything else.This has two limitations:
Prior art
Volto solves this with a central, configurable mapping:
config/Workflows.js→config.settings.workflowMapping, consumed by all components that render workflow states.Proposal (to be discussed)
@plone/registry(e.g.config.settings), with the current four entries as the default.@plone/contentsand@plone/cmsui. Open question: which package may host it so that both can depend on it (@plone/layout?@plone/componentswould need to stay free of Plone-specific logic per the conventions).Acceptance criteria
References
packages/contents/components/ReviewState.tsxpackages/cmsui/components/History/HistoryView.tsx(statusDotClass)src/config/Workflows.js,settings.workflowMapping