Add corrigenda

[CMKMS-LINZ]

User Story

As a NZGB data manager, I want add a 'corrigenda' to an existing 'gazette notice', so that I can meet my statutory obligations in publishing this information to the public.

This is instead of having to add this information into the generic 'note' information which appears above the 'gazette notice' in the UI and doesn't show the relationship between the corridenda and the gazette notice.

Acceptance Criteria

• [ ] User can add a corrigenda with 'name change type' of 'corrigenda' (TODO: do name change types already exist or is that a new concept?)
• [ ] Corrigenda is related to an existing gazette notice
• [ ] User can add additional corrigenda to the same gazette notice
• [ ] Stores a history of corrigenda
• [ ] Corrigenda and history is exported to the web app export
• [ ] Corrigenda and history is exported to the LDS export (TODO: confirm if this is needed)

Additional context

The NZGB is required by its Act to show all 'statutory references' that have affected official place names. This included where corrigenda (corrections) or minor amendments have also been notified in the NZ Gazette. The way a gazetted corrigendum works is typically to 'replace' the incorrect information with the corrected information. Refer here for an example: https://gazette.govt.nz/notice/id/2019-ln5815?noticeNumber=2019-ln5815

The original (incorrect) gazette remains the 'authorising gazette' which say, makes a name official, but it must be read together with the corrigenda.

Currently the Gazetteer is not set up to support this kind of hierarchical relationship.

What we want is a new gazetteer.name_subevent table, keyed to gazetteer.name_event on the event ID, so ultimately we could show something like:

more like this:

We would then need the plugin to show the field so users could edit it, and possibly add it to the data export and get Datacom to enable the web application to show it.

We can add corrigenda as standard 'events' but currently this means that they chronologically appear at the top of the list of events, and unless we use work around like writing an annotation that gets published, there is no relationship shown between the corrigendum and the authorising gazette event.

[billgeo]

@SPlanzer can you please provide an estimate for this.

[SPlanzer]

Task	Skills required	Questions / Comments	crude time estimate
Fully understand requirements * This should be a sit down with users	UX		.5 day
Produce design document and get user agreement as well as feedback from db dev / arch	Database Architecture		1 day
Add new table (gazetteer.name_subevent ) FK to gazetteer.name_event Index Grant use to users PgTap tests	Postgres DB Development	What are the columns required? are most of the data still stored in the name event_table? (Therefore just name_event.id and corrigenda in the new table?) Do all name_events tie to a subevent?	1 day
Add trigger to update user and time values for new table	Postgres DB Development	May not be required if majority of data is part of the name_event and user and data is referenced there	.5 day
Update Plugin form Update javascript and Html template Update plugin python data model	JS and HTML skills python		5 days (related to level of JS skills)
Create history table for the new gazetteer.name_subevent Create table Create trigger to keep history table updates * Add pgtap tests	Postgres DB Development		2 days
Write plugin automated tests for new functionality	Python Testing		2 day
Expand export functionality to include new table	Postgres DB Development		2 day
Dev Release	Developer		.5 day
UAT Testing DB Plugin * Export functionality	Gaz plugin expert		2 days
Bug Fixing & further testing	Python / Postgres / JS / HTML		2 days
Update developer notes	Developer		.5 days
Update user notes	Gaz plugin expert		.5 days
Production release of plugin	Developer		.5 days
		Total	Approx 2 sprints

[CMKMS-LINZ]

• columns would be the same as for a name_event, though for event_type there would only be 'Corrigenda' and 'Amendments' I think. The exception would be an additional column for the subevent_id keyed to the event_id. It would be important to have the name_id as well (even though it's not the key).
• Every name_subevent must tie to an existing name_event (vice versa doesn't make sense)

[billgeo]

Thanks @SPlanzer. I have communicated the estimate to Wendy. Putting this back on the backlog for now.