Expose observations on `/api/approvalStatuses` and confirm the CSV auto-approve path

[ombhardwajj]

As an integration consumer, I need the approval API to return the coded answers, so that systems outside Avni can read the reason a record was rejected.

Acceptance Criteria

• A system reading approvals through the API sees the form answers alongside the status. Verify: GET /api/approvalStatuses includes them for decisions that have them.
• Decisions without answers come back exactly as they do today. Verify: no new key, or an explicit null — never an error.
• Approving records in bulk from a spreadsheet still works when an approval form is attached. Those records simply carry no answers, because nobody opened a form. Verify: import with autoApprove=true succeeds and writes null observations.
• Bulk approval where no approval form is attached behaves exactly as it does today.

Technical Details

• avni-server-api/src/main/java/org/avni/server/web/response/EntityApprovalStatusResponse.java:8-16 — the response is a LinkedHashMap built with human-readable keys ("Entity ID", "Approval status comment", …). Add the observations after "Approval status comment", rendering them through Response.mapObservations(conceptRepository, conceptService, …) — the helper every other /api/* response already uses. It emits {"<question name>": "<resolved answer>"}, resolving coded answer UUIDs to concept names via ConceptService.getObservationValue and applying the API-version date normalisation.

  Do not use ObservationService.constructObservations. An earlier version of this story named it and claimed it matched the other API responses; both halves were wrong. It is the web/DEA contract helper (EncounterService, IndividualService use it), it returns a list of ObservationContract rather than a name-keyed map, and it leaves coded values as raw UUIDs — so an integration reading /api/approvalStatuses would get a different shape from /api/subjects, which is the opposite of this story's point. It also opens two problems mapObservations avoids: a per-row concept lookup (N+1 across a page) and an NPE surface on Subject-datatype answers whose referenced subject is voided or out of RLS scope.

• avni-server-api/src/main/java/org/avni/server/importer/batch/csv/writer/EntityApprovalStatusWriter.java:26-30 — no code change expected. It calls entityApprovalStatusService.createStatus(...), which story 2 deliberately leaves alone, so rows arrive with null observations. This story is to prove that and add the regression test, not to change behaviour.

Do NOT:

• Do not block CSV import when an Approval form is mapped. That was considered and rejected in the spec: bulk import is an administrative action, and blocking it would break existing imports for any org that later attaches a form.
• Do not add observations to the CSV upload format. Supplying form answers per row is a much larger feature and is not in scope.

Testing Gotchas

• /api/approvalStatuses is gated by @PreAuthorize("hasAnyAuthority('user')") and then checkApprovePrivilegeOnEntityApprovalStatuses, which throws if the caller lacks the approve privilege for any entity type in the page. A test user needs the right privileges or the endpoint 403s before serialisation is reached.
• The response keys contain spaces and are order-sensitive (LinkedHashMap). Assert on content, not on a serialised string.
• autoApprove reaches the writer as a @Value("#{jobParameters['autoApprove']}") String, parsed with Boolean.parseBoolean. Anything other than "true" is false — a common source of confusing test results.

---

avni-models

---

Epic: avniproject/avni-product#1901

[ombhardwajj]

Review of the #1053 commits (88f3b1a4f, 9963e766e, 1e630439f). One change to make, and the card was wrong before you were — I have corrected it above.

The answers come back in a different shape from every other /api response

EntityApprovalStatusResponse renders through ObservationService.constructObservations. Every other /api/* response uses Response.mapObservations:

observationsResponse.put(concept.getName(), conceptService.getObservationValue(concept, value));

which emits {"Reason for rejection": "Duplicate entry"} — question name, resolved answer name. constructObservations is the web/DEA contract helper (EncounterService, IndividualService use it); it returns a list of ObservationContract and ends with setValue(entry.getValue()), the raw jsonb. A rejection reason is almost always a coded question, so an integration reading /api/approvalStatuses gets answer UUIDs where /api/subjects gives it names, and Date answers skip the API-version normalisation ConceptService.getObservationValue applies.

The UUID is technically resolvable in-payload, since ConceptContract.create(questionConcept) embeds the answer list — but that is a different contract on the same API surface, which is the opposite of what this story wanted.

Please switch to Response.mapObservations(conceptRepository, conceptService, …).

This one is my fault, not yours. The card said "rendering them through ObservationService.constructObservations(...) so the output matches the observation shape other API responses use". Both halves of that were wrong — it is not what other API responses use, and it does not match their shape. You implemented what was written. The card now names mapObservations and says explicitly not to use constructObservations.

Two things resolve themselves with that switch, so I am not raising them separately:

• N+1 per page — constructObservations does a conceptRepository.findByUuid per observation plus ConceptContract.create walking conceptAnswers, inside the per-row loop in EntityApprovalStatusApiController:53. A sync-style integration pulling a page issues hundreds of queries where it previously issued none.
• A new NPE surface — getObservationContract dereferences the concept without a null check, and for a Subject-datatype answer calls convertIndividualToContract(individualRepository.findByUuid(...)) on a possibly-null individual. If an approval form carries a Subject question whose answer references a voided subject, or one outside the API user's RLS scope, the whole page 500s rather than one row degrading.

Otherwise good

The null guard on getObservations() before calling constructObservations is the right call and the comment explains it well — decisions predating the feature, and every decision in an org that never attaches a form, have a NULL column and would otherwise 500 on a @NotNull argument.