Release Track Picker UI from the existing design
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Build the Release Track Picker UI from the existing design
Parent epic: dotCMS/core#35693 · Workstream B (Self-service) · Post-launch
Background
A design for the "Release Track Picker" already exists. This issue builds it on the surface chosen in the dotCMS/private-issues#654 ADR (dotAdmin portlet or Cloud Console), backed by the public REST API. It is the self-service replacement for the interim support-ticket flow.
Scope
- Implement the picker per the existing design: current track, available tracks with plain-English descriptions, current version per track, and expected next-update window for this environment.
- Confirmation flow on change, including the explicit note that moving slower does not roll the version back (forward-only).
- Wire to the dotCMS/core#36529 REST API for read and change; surface authz errors gracefully.
- Handle the change-in-flight / next-window messaging consistent with the 2-week cadence.
Out of scope
- API and data model (#36528/#36529).
- Cadence or version-pin controls (deferred by the epic).
Acceptance criteria
- Picker renders current track, options, per-track version, and next-update window.
- Change flow includes forward-only confirmation and calls the API.
- Authz honored (only permitted identities can change).
- Matches the approved design.
Depends on
- dotCMS/private-issues#654 (which surface/auth).
- dotCMS/core#36529 (data + change operations).
Part of the Evergreen Release Tracks epic. Parent: dotCMS/core#35693.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the approved design and dotCMS/private-issues#654 to determine whether this belongs in the dotAdmin portlet or Cloud Console. Then read dotCMS/core#36529 for the REST API contract and verify the acceptance criteria: track details, forward-only confirmation, authorization handling, and change-in-flight messaging are all covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, cloud, frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100