KAS-4896: change query to only update BIS docs on latest agendaitem based on agenda-activity #2272
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://kanselarij.atlassian.net/browse/KAS-4896
https://chat.semte.ch/group/kanselarij-dev?msg=8hM2zfYWrtmM9SdXr
We have some places where we do a query to all agendaitems on designagenda of a subcase.
In reality this is mostly 1 result.
Only in this case it's 2.
We should only ever update 1, the latest one.
But it also depends on what the user wants.
In this change I changed 2 counts of where we did this.
One was the
piece-upload
.One was the
agendaitem-subcase-sync
The second one also means that changing titles and mandatees of a subcase wont be pushed to the agendaitem that is on the retracted agenda (if it has already been resubmitted to a new agenda)
If it was retracted and updates happen before resubmitting, we will still update the retracted agendaitem like normal.
That makes sense to me, so I didn't force a check on the
decision-result-code
as suggested in the ticket.This might need some user feedback as to what is allowed in this scenario.
We also have the
linked-pieces
logic setup so we update all agendaitems on designagendas.I have not touched that but we might have to look into that
We also use that query in
saveGovernmentAreas
in theCasesCaseSubcasesSubcaseIndexController
We set 'formally not yet ok' on all designagendas. which is probably unwanted in this scenario (changing government areas in general should maybe not trigger a formally ok reset ...)