Concourse & Jira DC Portal

🔹 Put Simply

Introduce structured change sets into Admin Portal so that content edits (manual or via API) can be grouped, reviewed, tested, and published in a controlled governance workflow with full version history.

🔹 Why It Matters

• 📦 Instead of treating each edit independently, grouping changes into change sets supports transparency, testing, and coordinated governance.

• 🛠️ Admin Portal now supports API-driven updates that generate change sets automatically—users need visibility into these and control over how changes are grouped and reviewed.

• 🔐 All content—whether templates, assets, or work items—must go through a review and sign-off process before hitting production.

• 🧪 Change sets can be tested in the Concourse Scoping UI by reviewers before being published, reducing the risk of bad data deployment.

• ✅ This workflow is essential to governed data quality, especially as more content is shared across delivery teams, offerings, and client engagements.

🔹 High-Level Acceptance Criteria

1. Change Set Management UI

   • Given I am editing content in Admin Portal,
     When I begin making changes,
     Then I should be prompted to either:

     • Add changes to an existing change set I have access to, or

     • Create a new change set with a name and description.

2. View and Reassign Changes Across Change Sets

   • Given a user has changes across multiple change sets,
     When viewing the list of changes,
     Then they should be able to move individual changes between change sets to group them more logically.

3. Audit Trail Within Each Change Set

   • Given a change set contains multiple changes,
     When I open the change set,
     Then I should see a full diff log per change, including:

     • Changed fields

     • Before/after values

     • Editor and timestamp

4. Reviewer Workflow for Sign-Off

   • Given a change set is marked as ready for review,
     When a reviewer accesses it,
     Then they can:

     • Comment on changes

     • Approve changes

     • Reject with required edits

     • Sign off for publishing

5. Integration with Concourse Scoping UI

   • Given a change set affects scoped content (e.g. work item templates),
     When a reviewer previews the change set,
     Then it should be testable in an isolated view using the Concourse Scoping UI before being published.

6. Publishing Requirements

   • Given a change set has been reviewed and signed off,
     When the user clicks “Publish,”
     Then all changes are written to the production database and marked as published.

7. Role-Based Access

   • Given different roles exist (Editor, Reviewer, Admin),
     When interacting with change sets,
     Then permissions should restrict who can edit, move, sign off, and publish.

8. API-Triggered Change Set Visibility

   • Given a change set is created via API,
     When I log into Admin Portal,
     Then I should be able to see and manage any change sets I own or have access to.