fix: allow deletion of scheduled change requests

[matthewelwell]

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

• I have run pre-commit to check linting
• 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

Allow change requests that are scheduled for the future to be deleted.

Resolves #3710

How did you test this code?

Added 2 new unit tests.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 4, 2024 9:38am
flagsmith-frontend-preview	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 4, 2024 9:38am
flagsmith-frontend-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 4, 2024 9:38am

[github-actions]

Uffizzi Preview deployment-49429 was deleted.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.90%. Comparing base (eca05ca) to head (08dcfb5).
Report is 8 commits behind head on main.

❗ Current head 08dcfb5 differs from pull request most recent head 519a853. Consider uploading reports for the commit 519a853 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3713      +/-   ##
==========================================
+ Coverage   95.89%   95.90%   +0.01%     
==========================================
  Files        1101     1101              
  Lines       34568    34697     +129     
==========================================
+ Hits        33149    33277     +128     
- Misses       1419     1420       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[khvn26]

I'm approving this as I don't see any problems in code, but it slightly worries me from the UX perspective.

I'd much rather continue restricting deletion of scheduled CRs in the backend, adding a UI flow which offers users to remove the schedule (i.e., clear the related live_from attributes) prior to deleting the CR.

This would make this process more transparent and resilient to human error, IMO.

[matthewelwell]

I'm approving this as I don't see any problems in code, but it slightly worries me from the UX perspective.

I'd much rather continue restricting deletion of scheduled CRs in the backend, adding a UI flow which offers users to remove the schedule (i.e., clear the related live_from attributes) prior to deleting the CR.

This would make this process more transparent and resilient to human error, IMO.

This would be quite challenging I think, because we would need to 'unpublish' the change request at the same time (which isn't currently possible). Otherwise, you would essentially be marking the change request as 'complete'.

This does make me think that there might be an issue I haven't considered here though that there is a task added to the queue when a scheduled change request is published which we may need to clear from the queue. This could be challenging, however due to issues interacting with the task queue db table. I'll take a look.