feat: edit versioned change request

[kyle-ssg]

Thanks for submitting a PR! Please check the boxes below:

• I have added information to docs/ if required so people know about the feature!
• I have filled in the "Changes" section below?
• I have filled in the "How did you test this code" section below?
• I have used a Conventional Commit title for this Pull Request

Changes

Allows editing a versioned change request

• Opens up the edit feature modal with the changesets applied
• Corresponding changes are then converted back to changesets and updated with the change request

How did you test

Edit.Change.Requests.mov

this code?

Edit a change request in a versioned environment

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

3 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
docs	Ignored	Preview	Jan 6, 2026 2:22pm
flagsmith-frontend-preview	Ignored	Preview	Jan 6, 2026 2:22pm
flagsmith-frontend-staging	Ignored	Preview	Jan 6, 2026 2:22pm

[github-actions]

Docker builds report

Image	Build Status	Security report
ghcr.io/flagsmith/flagsmith-api-test:pr-6368	Finished ✅	Skipped
ghcr.io/flagsmith/flagsmith-e2e:pr-6368	Finished ✅	Skipped
ghcr.io/flagsmith/flagsmith-frontend:pr-6368	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith-api:pr-6368	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith:pr-6368	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith-private-cloud:pr-6368	Finished ✅	Results ✅

[matthewelwell]

My understanding of the requirements, written in test scenarios. @kyle-ssg is this your understanding of the behaviour? Anything else that we should be testing?

Non-scheduled CRs

1. User can edit unpublished CRs they created
2. User cannot edit unpublished CRs created by another user
3. User cannot edit published CRs

Scheduled CRs

1. User can edit unpublished scheduled CRs that they created
2. User cannot edit unpublished scheduled CRs created by another user
3. User cannot edit published scheduled CRs

[kyle-ssg]

My understanding of the requirements, written in test scenarios. @kyle-ssg is this your understanding of the behaviour? Anything else that we should be testing?

@matthewelwell The exception to that at the moment is anyone can edit a change request if they have the ability to create one. I can see a use case for this tbh, if someone is away we should let someone with appropriate permissions to do this.

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Bug: Segment override priorities from changeset are discarded

When editing a versioned change request, segment override priorities from the changeset are set at lines 119 and 166 (priority: changedFeatureState.feature_segment?.priority || 0), but then immediately overwritten with array indices at lines 185-189. Since the save function at create-feature/index.js:604 uses the top-level priority property for feature_segment.priority, any priority reordering specified in the original change request will be lost when the edit is saved. The segments also remain in the current live order rather than being sorted by the changeset's intended priorities.

Additional Locations (1)

• frontend/common/providers/withSegmentOverrides.js#L118-L119

 

[cursor]

Bug: Legacy change requests ignored in versioned environments

The condition logic creates a gap for legacy change requests. The first branch requires isVersioned && changeRequest.change_sets, and the second requires !isVersioned && changeRequest.feature_states?.[0]. If an environment has versioning enabled but a change request was created before versioning (using feature_states instead of change_sets), neither branch executes. The changedEnvironmentFlag would retain the current live values rather than the change request's intended values, causing the edit modal to display incorrect data.

 

[matthewelwell]

@matthewelwell The exception to that at the moment is anyone can edit a change request if they have the ability to create one. I can see a use case for this tbh, if someone is away we should let someone with appropriate permissions to do this.

My concern with that is that we don't have any indication when a change request has been edited. If we're not going to add that (which is probably the correct approach for now), I would rather restrict it to the author, or environment admins for now.

At the moment, it's only the author that can delete a change request for example - I think we should add environment admins to this list, but I don't think anyone should be able to edit or delete a CR.

[matthewelwell]

I've aligned the BE with my expectations in a PR here.

[kyle-ssg]

Identified Issues

1. (Blocker) Editing a scheduled change request can revert the date to the current datetime

2. (Non-blocking) Editing a change request shows 'Change Request Created' in the toast message

Fixed