Implement an additional configurable case closing behavior which allows for an 'eindstatus' to be delayed/ignored in actualiseerZaakStatus when recieved before the case is closed by 'einddatum' #414
We already have a case closing scenario for when the 'eindstatus' is set in an actualiseerZaakStatus message, before the updateZaak message that sets the 'eindatum' (and resultaat). This behavior should cover the scenario of an additional geefZaakDetails in between the actualiseerZaakStatus and updateZaak messages.
Because actualiseerZaakStatus contains the 'eindstatus', the case is closed by OpenZaak as per ZGW specification. This also results in the case having 'einddatum' set. The ZDS application then sees that the case is closed in the geefZaakDetails and throws an error, because it expect the case not to be closed yet. The ZDS standard specifies that a case is closed when 'einddatum' is set, which would be in the updateZaak message that would come after actualiseerZaakStatus and geefZaakDetails.
The initial solution should be to add a property in the translation profile that, when enabled, will ignore specifically the 'eindstatus' for a given zaaktype. The following geefZaakDetails will then indicate that the case is indeed not closed yet, which will trigger the ZDS application to send the updateZaak message that sets 'einddatum' (and resultaat). From here 2 things could happen when it comes to the 'eindstatus'. If the updateZaak message contains the 'eindstatus' with verwerkingsoort "I", ZaakBrug should validate if it exists, and if that is not the case, add the status. This will then trigger the case to be closed on the ZGW side due to the 'eindstatus' being set. Alternatively, if updateZaak does not contain the 'eindstatus' with verwerkingsoort "I", it should trigger an additional case closing behavior where ZaakBrug adds the 'eindstatus' if 'eindatum' is set, but no 'eindstatus' is present.
Initially we should try to ignore the 'eindstatus' in actualiseerZaakStatus. If it turns out to result in loss of information, we can try to work on delaying it instead. This will be quite difficult to do without keeping state, which we try to avoid at all cost.
We already have a case closing scenario for when the 'eindstatus' is set in an actualiseerZaakStatus message, before the updateZaak message that sets the 'eindatum' (and resultaat). This behavior should cover the scenario of an additional geefZaakDetails in between the actualiseerZaakStatus and updateZaak messages.
Because actualiseerZaakStatus contains the 'eindstatus', the case is closed by OpenZaak as per ZGW specification. This also results in the case having 'einddatum' set. The ZDS application then sees that the case is closed in the geefZaakDetails and throws an error, because it expect the case not to be closed yet. The ZDS standard specifies that a case is closed when 'einddatum' is set, which would be in the updateZaak message that would come after actualiseerZaakStatus and geefZaakDetails.
The initial solution should be to add a property in the translation profile that, when enabled, will ignore specifically the 'eindstatus' for a given zaaktype. The following geefZaakDetails will then indicate that the case is indeed not closed yet, which will trigger the ZDS application to send the updateZaak message that sets 'einddatum' (and resultaat). From here 2 things could happen when it comes to the 'eindstatus'. If the updateZaak message contains the 'eindstatus' with verwerkingsoort "I", ZaakBrug should validate if it exists, and if that is not the case, add the status. This will then trigger the case to be closed on the ZGW side due to the 'eindstatus' being set. Alternatively, if updateZaak does not contain the 'eindstatus' with verwerkingsoort "I", it should trigger an additional case closing behavior where ZaakBrug adds the 'eindstatus' if 'eindatum' is set, but no 'eindstatus' is present.
Initially we should try to ignore the 'eindstatus' in actualiseerZaakStatus. If it turns out to result in loss of information, we can try to work on delaying it instead. This will be quite difficult to do without keeping state, which we try to avoid at all cost.