feat: add the ability to execute status actions when the proposal status is updated manually#1441
Conversation
…elated methods and types
…g and introducing WorkflowStatus model
…lowStatusId instead of id
…ntroducing CreateWorkflowConnection mutation
…rget status lookups
…vents table and updating related references
…usActionsOnConnection
…lowStructure method
…onsistency in workflow management
…efactoring IsProposalSubmittedGuard
…andling and refactoring related methods
…error for missing proposal workflow
… GuardFn and refactoring related guards
…ent metadata handling
…tatusConnectionId and refactor related properties
…authorization checks for proposal assignments
…orkflow migration scripts
… for proposal status filtering
…cify-which-actions
|
Two comments:
|
…cify-which-actions
…cify-which-actions
I have added the events and actions to be displayed when changing the proposal status manually.. You can only select status actions that lead to the status that is selected. This is to enable the behavior how itworkflows were functioning in the past. |
yoganandaness
left a comment
yoganandaness
left a comment
There was a problem hiding this comment.
lgtm.
@jekabs-karklins I hope I should be doing the same for Experiment safety status change as well.
mutambaraf
left a comment
mutambaraf
left a comment
There was a problem hiding this comment.
Looks like we have dropped a test file experimentSafetyWorkflow.spec.ts was it by mistake or we will add them back
…cify-which-actions
Certainly a mistake. Thanks I'll put it back. |
mutambaraf
left a comment
mutambaraf
left a comment
There was a problem hiding this comment.
Looks good just a few comments
| disabled={isSubmitting} | ||
| data-cy="status-selection" | ||
| <Grid item xs={12} md={8}> | ||
| <div style={{ height: '500px', border: '1px solid #ddd' }}> |
There was a problem hiding this comment.
I do not know is it a good idea to hard code some of these colours.
There was a problem hiding this comment.
I removed the border, I think it looks better without actually
| } | ||
| }); | ||
| }, [api, selectedProposalsWorkflowIds[0]]); | ||
|
|
There was a problem hiding this comment.
This looks like a duplication we may need to remove one of the useEffect hook.
…ions' into fix-xpress-workflow
…cify-which-actions
jekabs-karklins
deleted the
SWAP-5434-as-a-user-officer-i-want-to-specify-which-actions
branch
6 participants
Description
THIS PR IS BUILT ON TOP OF #SWAP-4949-workflow-overhaul
This PR adds the ability for the User Officer to execute status actions when he/she sets the proposal status manually.
Motivation and Context
After the workflow overhaul the status actions are attached to the transition, and not the status. In same cases when setting the proposal status the user officer would want to run the status actions accompanied with the transition leading to that status.
This PR handles three scenarios:
Changes
workflowConnectionIdparameter to thechangeProposalsStatusmutation inProposalMutations.ts, which is used to fetch the proposal workflow and run the status engine.changeProposalsStatusmutation to only run status actions ifworkflowConnectionIdis provided, improving the control over status change side-effects.proposals.cy.tsto cover the new functionality.How Has This Been Tested?
Added e2e
Fixes Jira Issue
https://jira.ess.eu//browse/SWAP-5434
Depends On
Tests included/Docs Updated?