feat: Add transferValue to registration view

[RubenGeo]

AB#44658

Describe your changes

• Add a computed transferValue column (paymentAmountMultiplier * program fixedTransferValue) to the registration view, also exposed via the API
• The refinement also mentioned Also use this when creating transactions however I decided against this
  • It's possible to pass in the transfer amount when create a payment (dry run). So than the transferValue in the registraiton view cannot be used because than the program fixedTransferValue is not perse used.

Checklist before requesting a code review

• I have performed a self-review of my code
• I have addressed all Copilot comments
• I have asked the design team to review these changes, or: The changes do not touch the UI/UX
• I have added tests for my changes, or: Adding tests is unnecessary/irrelevant
• I have made sure that all automated checks pass before requesting a review
• I have updated all documentation where necessary
• I have checked the list of integrations with the 121 API for changed endpoints
• I do not need any deviation from our PR guidelines

Portal preview-deployment

https://happy-rock-0411d2003-8857.westeurope.3.azurestaticapps.net

[Copilot]

🟡 Changes recommended

Unresolved TypeScript compilation blockers and missing API metadata and test coverage remain.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds computed transferValue to registration views and the API, calculated as paymentAmountMultiplier × fixedTransferValue.

Changes:

• Adds the database view column and migration.
• Exposes filtering, sorting, enum, and Swagger support.
• Updates tests and expected response attributes.

File summaries

File	Reviewed change	Final review notes
services/121-service/test/registrations/pagination/pagination-data.ts	Updates expected response attributes.	No final comments.
services/121-service/test/registrations/calculate-payment-amount-multiplier.test.ts	Tests the calculation.	No final comments.
services/121-service/swagger.json	Documents filter parameters.	No final comments.
services/121-service/src/registration/enum/registration-attribute.enum.ts	Adds the new attribute.	Critical (1 vote): Add the missing portal ATTRIBUTE_LABELS entry to avoid a TypeScript build failure.
services/121-service/src/registration/entities/registration-view.entity.ts	Defines the computed column.	Critical (3 votes): Update registrationViewAttributeNamesRecord to avoid a service compilation failure.
services/121-service/src/registration/const/filter-operation.const.ts	Enables filtering and sorting.	Moderate (1 vote): Update advertised program filter metadata. Nit (1 vote): Add filter and sort test coverage.
services/121-service/src/migration/1789485881583-add-transfer-value-to-registration-view.ts	Recreates the database view.	No final comments.

Review details

Suppressed comments (2)

services/121-service/src/registration/const/filter-operation.const.ts:58

• This makes transferValue filterable at the registrations endpoint, but the program API's advertised filterableAttributes is built from the hard-coded genericPaAttributeFilters in ProgramRegistrationAttributesService, which is not updated here. Clients that discover filters from /programs/:programId therefore will not see this new filter; add it to that metadata list (and cover it) or remove the filter exposure.

      transferValue: AllowedFiltersNumber,

services/121-service/src/registration/const/filter-operation.const.ts:38

• The new sortable/filterable API paths are not covered by the added test, which only checks the default response field. The pagination suite already tests the analogous paymentAmountMultiplier behavior; add transferValue filter and sort cases so this newly exposed API contract is verified.

      'transferValue',

• Files reviewed: 7/7 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

Add transferValue as a read-only portal generic attribute so the registrations table displays the computed column.

Review details

Suppressed comments (2)

interfaces/portal/src/app/domains/program/program-attribute.helpers.ts:10

• This label is never enough to create the new table column: createPaAttributeColumns only emits fields found in registrationAttributes, but getGenericAttributes does not add transferValue to that list. As a result, the backend exposes the filter and value while the portal silently omits the Transfer value column. Add it as a read-only generic attribute (and keep it out of the update form) so the computed value can actually be displayed.

  transferValue: $localize`:@@attribute-label-transferValue:Transfer value`,

services/121-service/src/program-registration-attributes/program-registration-attributes.service.ts:47

• Adding transferValue here makes the backend advertise a paAttributes filter to the portal, but RegistrationAttributeService.getGenericAttributes() still omits GenericRegistrationAttributes.transferValue. RegistrationsTableColumnService.createPaAttributeColumns() only creates a column when it finds a matching normalized attribute, so the new field/filter is silently absent from the registrations table. Add it to the portal's generic attributes and mark it non-editable because it is computed.

      'transferValue',

• Files reviewed: 19/19 changed files
• Comments generated: 0 new
• Review effort level: Lite

[RubenGeo]

Re: the "Nit" suggestion on filter-operation.const.ts:38 to add dedicated filter/sort test cases for transferValue — I considered this but decided against adding them, and removed the two I'd initially added (sort-registration.test.ts / filter-registration-range.test.ts).

Reasoning:

• registration_view is a real Postgres VIEW, so once created, transferValue is just a normal output column of that view. Sorting/filtering on it goes through the exact same nestjs-paginate + TypeORM path as any plain column like paymentAmountMultiplier — there's no distinct "computed column" mechanism being exercised at query time.
• transferValue = paymentAmountMultiplier × program.fixedTransferValue, and for the test program fixedTransferValue is a fixed positive constant. Multiplying by a positive constant is a strictly monotonic transform, so a dedicated DESC-sort test on transferValue produces the identical ordering as the existing paymentAmountMultiplier sort test on the same registrations, and a dedicated GT filter test selects the identical reference IDs as the existing paymentAmountMultiplier GT test. They don't exercise anything transferValue-specific — not the formula, not null-handling (the one real behavioral difference, since transferValue can be null when fixedTransferValue is unset, while paymentAmountMultiplier never is — neither test happens to touch that case anyway).

What still covers this newly-exposed API surface without duplicating existing coverage:

• The transferValue entry now added to filterAssertionConfig in filter-registration.test.ts, which smoke-tests filtering on every generic filterable attribute (including this one).
• calculate-payment-amount-multiplier.test.ts, which is the actual unique test of the transferValue formula.
• pagination-data.ts's expectedAttributes, which asserts transferValue is present in the API response shape.
• create-program.test.ts's snapshot, which confirms transferValue is correctly registered as filterable/sortable metadata.

Happy to add the dedicated tests back if there's a scenario I'm missing, but as-is they felt like pure duplication of the paymentAmountMultiplier coverage rather than new confidence.