Problems in and solutions for ZTC 1.3
There are numerous problems within the standard ZTC 1.3. For some of these problems, we have posted issues on Github for ZGW. In the table below we list the Github issues and indicate how various Roxit components (should) deal with them.
| Problem (short) | Github issue | Solution in ZTC registration component itself | Solution in ZRC, BRC or DRC | Solution in ZTC config app (PMA process, casetype management) | Solution in client app |
|---|---|---|---|---|---|
| ztc-013 is unclear | #2482 | Apply the rule only to roltype-zaaktype, eigenschap-zaaktype, statustype-zaaktype, zaaktypeinformatieobjecttype-zaaktype and resultaattype-zaaktype. | |||
| Filter on status for object types without status unclear | #2479 | Filter on status of related case type | |||
| Scope geforceerd verwijderen (forced delete) unclear | #2478 | Scope must be ignored | Do not give the possibility to delete pubished types (in stead give the casetype an end date) | ||
| Scope geforceerd schrijven (forced update) superfluous | #2477 | Scope must be ignored | Give a warning when correcting | ||
| Double relationship: BT-> ZT on BT and ZT-> BT on ZT | #2475 | Relationship BT-> ZT is not stored (or retrieved) | When creating or updating a Besluit with a related case, check whether the casetype of the case is related to the besluittype of besluit | Only allow config on ZT->BT. Do not give the possibility BT-> ZT | Retrieve possible BT’s by a GET on ZT. The get on BT will not return ZT’s |
| Which URL’s of related ZT, BT or IOT (here related type or “RT”) are returned in GET on BT, ZT, ZIOT and IOT (here objecttype or “OT”) | #2474 | Return the following url’s of RT: <ul><li>OT has a relationship with RT;</li><li>RT has concept=false;</li><li>begingeldigheid of RT <= today;</li><li>eindegeldigheid of RT is empty or > today.</li></ul> | - | If the name (= description, identification) of RT also is available in the response - show that. Otherwise do a GET on the RT and show its name. | - |
| ZTC: attribute name of ZT identificatie en ZT datumgeldigheid is different in response resultaattype | #2473 | zaaktypeIdentificatie and datumgeldigheid in response | use zaaktypeIdentificatie and datumgeldigheid from response | ||
| Business rule ztc-011 is ambiguous and superfluous | #2471 | Do not implement ztc-011 | Do not implement ztc-011. Do use ztc-010 (with adjustments - see below) and ztc-009 | ||
| Business rule ztc-012 is unclear and superfluous | #2476 | Do not implement ztc-012 | Do not implement ztc-012. Do use ztc-010 (with adjustments - see below) and ztc-009 | ||
| Catalogus attribute is superfluous in POST/PUT/PATCH voor Resultaattype en Roltype | #2468 | Neglect the catalogue field in these calls | Don’t implement a possibility to add a catalogue to Resultaattype en Roltype | ||
| Unclear in which format BT and IOT are added to resultaattype and whether they are required | #2467 | For both BT and IOT: <ul><li>Don’t check on required (it is NOT required);</li><li>expect an array;</li><li>expect omschrijving (not url)</li></ul> | For both BT and IOT: <ul><li>Don’t check on required (it is NOT required);</li><li>support multiple (array);</li><li>show omschrijving (not url)</li></ul> | ||
| ztc-010 is unclear and should be rewritten | #2456 | If Roltype, Statustype, Eigenschap, Zaaktype-Informatieobjecttype, Resultaattype or Zaakobjecttype is related to ZT with concept=false then no POST/PUT/PATCH/DELETE is allowed except in correction mode | If Roltype, Statustype, Eigenschap, Zaaktype-Informatieobjecttype, Resultaattype or Zaakobjecttype is related to ZT with concept=false then no POST/PUT/PATCH/DELETE is allowed except in correction mode | ||
| New business rule begin/einde Geldigheid | #2455 | Apply to published versions of ZT with identical identifications, BT with identical descriptions, and IOT with identical descriptions: They may not have overlap in Geldigheid (validity). The period of validity (geldigheidsperiode) is the series of dates >= beginGeldigheid AND <= eindGeldigheid, (where empty eindGeldigheid is the highest possible date). | Apply to published versions of ZT with identical identifications, BT with identical descriptions, and IOT with identical descriptions: They may not have overlap in Geldigheid (validity). The period of validity (geldigheidsperiode) is the series of dates >= beginGeldigheid AND <= eindGeldigheid, (where empty eindGeldigheid is the highest possible date). | ||
| POST zaken not backwards compatible because deelzaaktypen required | #2452 | Do not check on presence Deelzaaktypen | Do not require deelzaaktypen | ||
| GET ZT -> informatieobjecttypen should return array (not string) | #2445 | Return multiple IOT (if present) in response | Support multiple IOT in response | Support multiple IOT in response | |
| POST besluittype should support related ZT | #2437 | Allow the field but neglect it (see #2475) | Do not support this attribute (see #2475) |