Edit-action

[cibelius]

Description

Resolves: #10939
cc pr: opencrvs/opencrvs-countryconfig#1182
farajaland pr: opencrvs/opencrvs-farajaland#1874

See small demo video here! https://opencrvsworkspace.slack.com/archives/C02LU432JGK/p1765505724107889

Edit-action replaces the editing as part of validation/registering functionality we had previously.

• Add record.declared.edit scope and give it to relevant test users
• Add custom trpc functions editAndRegister & editAndDeclare
• Add new core action: ActionType.EDIT
• Add Edit-action flow for declared & unregistered events
  • The edit action menu has 3 actions available (depending on user scope):
    • Register with edits
    • Declare with edits
    • Cancel edits
• Made edits are shown on edit action audit modal
• Refactor useUserDetails.ts -> useCurrentUser.ts
• Refactor user detail logic from EventHistory.tsx -> useUserDetails.ts so it can be used in EditPageBanner.tsx

Follow-up issue for replacing current notify -> declare flow with edit: #11306. This would allow us to get rid of the 'Updated' functionality and a whole bunch of code.

Checklist

• I have linked the correct Github issue under "Development"
• I have tested the changes locally, and written appropriate tests
• I have tested beyond the happy path (e.g. edge cases, failure paths)
• I have updated the changelog with this change (if applicable)
• I have updated the GitHub issue status accordingly

[github-actions]

Oops! Looks like you forgot to update the changelog. When updating CHANGELOG.md, please consider the following:

• Changelog is read by country implementors who might not always be familiar with all technical details of OpenCRVS. Keep language high-level, user friendly and avoid technical references to internals.
• Answer "What's new?", "Why was the change made?" and "Why should I care?" for each change.
• If it's a breaking change, include a migration guide answering "What do I need to do to upgrade?".

[Nil20]

Great clean work so far. 🙌 Looked over mostly the commons and events change, although most changes are in client. 😄 Left a few comments for you to address.

[Nil20]

Having two probable DECLARE actions might have impact on some places that we would not be able to identify straight away. This could be one of those places.

We let the users search with legalStatuses.DECLARED.createdAtLocation to search with a location where a record was DECLARED. Maybe you can manually test if searching with this field works okay and add a test.

Suggestion: You can test it out by adding a field like this and see if gets populated with the correct value after a re-declare with edits is done.

[Nil20]

Is it right to validate the Edit action payload with validateNotifyAction? Is it because both can have incomplete input payload?

[Nil20]

these validation functions call FieldTypeMapping to have a zod schema for validating a field value. Like here, for notify actions firstname/surname of a name field can be empty.

For Edit action, that ({ firstname: 'Cihan', surname: undefined } ) should be validated as well. So, maybe FieldTypeMappings should be updated. And add a test case regarding this.

[Nil20]

Suggested change

	actions = sortedActions.filter((_, idx) => idx < secondLast || idx >= last)
	actions = [
	...sortedActions.slice(0, secondLast),
	...sortedActions.slice(last)
	]

might be a tad more readable