Currently: it seems that reviewing a destruction list with a processed review seems to show all zaken, where only the review items are expected. After fixing this (by using the in_review filter on the zaken endpoint) a new problem occurs:
After submitting the following error is returned:
"zakenReviews": [
"You can only provide feedback about cases that are part of the destruction list."
]
}
This may happen probably because in some cases the status of a destruction list item can be set to "removed" instead of "suggested", I've looked into into why this happens and I thinkg it's either due to too strict check:
hides "removed" results from the destruction list.
However, I'm confused about the meaning of DestructionListItemAction, does "keep" mean keep (don't destroy) the zaak or does it mean "keep" the review suggesting it to be removed. In any case: we should check the frontend API payload to validate if the correct behaviour is implemented and check if it works correctly.
NOTE: THIS MAY BE INTENTIONAL: https://github.com/maykinmedia/open-archiefbeheer/issues/372
Currently: it seems that reviewing a destruction list with a processed review seems to show all zaken, where only the review items are expected. After fixing this (by using the
in_review
filter on the zaken endpoint) a new problem occurs:After submitting the following error is returned:
This may happen probably because in some cases the status of a destruction list item can be set to "removed" instead of "suggested", I've looked into into why this happens and I thinkg it's either due to too strict check:
backend/src/openarchiefbeheer/destruction/api/serializers.py:414
or due to the filter (in_review) showing too many zaken:
backend/src/openarchiefbeheer/zaken/api/filtersets.py:223
Altering
filter_in_review
to:SUGGESTION
hides "removed" results from the destruction list.
However, I'm confused about the meaning of
DestructionListItemAction
, does "keep" mean keep (don't destroy) the zaak or does it mean "keep" the review suggesting it to be removed. In any case: we should check the frontend API payload to validate if the correct behaviour is implemented and check if it works correctly.