[OCRVS-11571] Metadata fields

[tahmidrahman-dsi]

Description

Clearly describe what has been changed. Include relevant context or background.
Explain how the issue was fixed (if applicable) and the root cause.

Link this pull request to the GitHub issue (and optionally name the branch ocrvs-<issue #>)

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?".

[makelicious]

This is not part of event declaration. It is a separate action form field.

[makelicious]

This is not part of event declaration. It is a separate action form field.

[makelicious]

This is not part of event declaration. It is a separate action form field.

[makelicious]

Overall looks good.

Does it feel ergonomic? Do we anticipate that everyone just destructs the event and goes forward with

const { declaration, metadata } = event

stylistic thing, so no biggie.

I commented on few places where I noticed that the ambiguity of previous field() method went unnoticed.

I dug deeper and it seems to be more recent change, reviewed by yours truly:
#11380

I did not remember that, so that's on me. However, we are in a situation where event.declaration is used for items that are not part of event declaration.

  parent: event.declaration('identity.http-fetch'),

@naftis what was the need for this, is there a way around it, or to create a separate helper?

[rikukissa]

Thanks @makelicious. I'm also thinking is there a need to distinguish between a field reference and a declaration value reference

    parent: event.declaration('tennis.style'),
    defaultValue: event.declaration('tennis.style')

would then be more a

    parent: field('tennis.style'),
    defaultValue: event.declaration('tennis.style')

reference. Or is it always just depending on context?

[naftis]

@makelicious The fix was to allow custom action form fields to depend on custom action form fields. So for example you can now have a custom action with a "fetch NID" -button that populates a text field.

Before the PR, the parent could only be a Declaration Field which broke interactivity in custom actions.

I did not consider new helpers etc, in my mind: field = a field in the FormFieldGenerator

[Zangetsu101]

Let's list down the references we want to provide for configuration purposes:

• EventIndex data (Used in EventOverview/Summary, workqueues) -- This is mostly value access
  • the declaration data
  • event metadata
• Form data -- can be value access or reference depending on context
  • can be declaration fields
  • action fields (in action forms, declaration review)
• Event data
  • the actions data to be used in form conditionals, certificate template filtering

Any other use cases come to mind? We probably need to maintain clear boundaries among them