Architecture #27278: Post-snippet migration fixes and cleanup in change-validation - Change validation - Issue Tracker

Actions

Copy link

Architecture #27278

open

Architecture #26903: Migrate change-validation snippets to Elm

Post-snippet migration fixes and cleanup in change-validation

Added by Véronique HAYAERT about 18 hours ago. Updated about 12 hours ago.

Status:

Pending technical review

Priority:

N/A

Assignee:

Véronique HAYAERT

Target version:

Rudder plugins - 9.0

Pull Request:

https://github.com/Normation/rudder-p...

Effort required:

Small

Name check:

To do

Fix check:

To do

Regression:

Description

This PR aims to finalise the migration of the change-validation lift snippets that have been migrated to Elm this far, which includes:

a modification in the ChangeRequestDetails Elm app and in the WorkflowService API : findNextStatus should return a list of possible next statuses rather than up to a single possible status
deleting the 4 lift snippets that have been migrated, i.e. ChangeValidationSettings.scala , ChangeRequestEditForm.scala , ChangeRequestChangesForm.scala , and ChangeRequestDetails.scala

Files

Peek 2025-07-15 11-30.gif (92 KB) Peek 2025-07-15 11-30.gif

Clark ANDRIANASOLO, 2025-07-15 11:52

Subtasks 1 (1 open — 0 closed)

Actions

Copy link

Updated by Véronique HAYAERT about 18 hours ago

Subtask #27279 added

Actions

Copy link

Updated by Véronique HAYAERT about 18 hours ago

Status changed from New to In progress

Actions

Copy link

Updated by Clark ANDRIANASOLO about 17 hours ago · Edited

File Peek 2025-07-15 11-30.gif Peek 2025-07-15 11-30.gif added
Status changed from In progress to New

Note : Some precision : findNextStatus could be kept into a single value, and the API implementation could just make a list out of possible states.
Here is what could be done :

The frontend needs to be able to accept a change request in Pending validation with either Pending deployment or Deployed as next status :

if the rights are sufficient, the frontend should make corresponding API calls to either /changeRequest/id/accept?status=pending deployment or /changeRequest/id/accept?status=deployed
the frontend should receive the list of status from the API, so the frontend only NEEDS the list in the API JSON response in the nextStatus field

The backend should then return a list : the API implementation uses the findNextStatus to put the direct next status in the nextStatus, but it could then be used to recursively create a list from all states, within the API implementation

Actions

Copy link