Skip to content

Add ability to configure Sigmax return state#1466

Open
bartjkdp wants to merge 2 commits intoAmsterdam:mainfrom
delta10:feat/configurable-sigmax-return-state
Open

Add ability to configure Sigmax return state#1466
bartjkdp wants to merge 2 commits intoAmsterdam:mainfrom
delta10:feat/configurable-sigmax-return-state

Conversation

@bartjkdp
Copy link
Contributor

@bartjkdp bartjkdp commented Sep 8, 2024

Description

This PR makes it possible to configure the Sigmax return state. Currently the status in Signalen always returns to "done external" (Extern: afgehandeld), but some municipalities would like to be able to set the status to "o" (Afgehandeld).

Checklist

  • Keep the PR, and the amount of commits to a minimum
  • The commit messages are meaningful and descriptive
  • The change/fix is well documented, particularly in hard-to-understand areas of the code / unit tests
  • Are there any breaking changes in the code, if so are they discussed and did the team agreed to these changes
  • Check that the branch is based on main and is up to date with main
  • Check that the PR targets main
  • There are no merge conflicts and no conflicting Django migrations
  • PR was created with the "Allow edits and access to secrets by maintainers" checkbox checked

How has this been tested?

  • Provided unit tests that will prove the change/fix works as intended
  • Tested the change/fix locally and all unit tests still pass
  • Code coverage is at least 85% (the higher the better)
  • No iSort, Flake8 and SPDX issues are present in the code

@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch 3 times, most recently from 75edebc to 1c886a4 Compare September 9, 2024 14:33
@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch 2 times, most recently from ffd72a0 to 8ab4d08 Compare October 8, 2024 17:24
@bartjkdp
Copy link
Contributor Author

bartjkdp commented Oct 8, 2024

We are currently testing this change in Leiden.

@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch from 8ab4d08 to 73808aa Compare October 21, 2024 07:45
@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch from 73808aa to 2665e19 Compare December 31, 2024 11:17
@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch from 2665e19 to 017e2a7 Compare December 24, 2025 12:12
@bartjkdp bartjkdp marked this pull request as ready for review December 24, 2025 12:13
@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch 2 times, most recently from fa7370b to 6160312 Compare December 24, 2025 12:14
@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch 8 times, most recently from 5feb8ef to 2adf7a8 Compare January 7, 2026 11:12
@bartjkdp bartjkdp force-pushed the feat/configurable-sigmax-return-state branch from 2adf7a8 to 4323527 Compare January 7, 2026 11:13
],
VERZONDEN: [
AFGEHANDELD_EXTERN,
AFGEHANDELD,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer if the state machine workflow is not adjusted for this use case. My prefered solution would be if the flow VERZONDEN -> AFGEHANDELD_EXTERN -> AFGEHANDELD is still used. I understand this is an extra database call for this specific use case, but keeping the correct flow is a fair trade-off for me.

Could you remove the change to the workflow, and instead do a double state change instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants