Dref3: rename `appeal_id` to `appeal_code`

[thenav56]

Summary

The dref3 API currently exposes appeal_id, but the value it holds is an appeal code (e.g. MDRTJ032), not an appeal DB pk.

On the current API, ?appeal_id=6 takes a dref.pk, not an appeal.pk, so the value is neither an appeal ID nor an appeal code. We rename to appeal_code and, make the filter multi-value and only use the appeal code

Breaking changes

	Before	After
Response field	appeal_id: "MDRTJ032"	appeal_code: "MDRTJ032"
Filter param	?appeal_id=6 (dref.pk)	?appeal_codes=MDRAM010,MDRTJ032 (comma-separated appeal codes)

Notes:

• Filter is plural (appeal_codes) because it accepts multiple values; response field stays singular (appeal_code).
• pk-based filtering is dropped. (Confirm: does any consumer still need it?)
• Detail lookup by appeal code is unaffected: /api/v2/dref3/MDRNG043/ keeps working.

Current behaviour verified on test envs

alpha-3 = new dref3 changes, alpha-4 = existing dref3; both share the same DB dump from staging.

• Detail by appeal code — works on both:
  • https://alpha-4-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/MDRNG043/
  • https://alpha-3-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/MDRNG043/
• appeal_code_prefix — works on both:
  • https://alpha-4-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/?appeal_code_prefix=MDRAM0
  • https://alpha-3-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/?appeal_code_prefix=MDRAM0
• appeal_id — single value works, semantics differ:
  • https://alpha-4-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/?appeal_id=6
    • this is the dref.pk (not appeal.pk), which resolves to appeal code MDRAM010
  • https://alpha-3-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/?appeal_id=MDRAM010
• Multiple values — not supported on either env, both return []:
  • https://alpha-4-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/?appeal_id=6,26
  • https://alpha-3-api.ifrc-go-nx.dev.togglecorp.com/api/v2/dref3/?appeal_id=MDRAM010,MDRTJ032

Tasks

• Add a new response field appeal_code. It holds the Appeal Code.
• Change the current response field appeal_id. It will hold the Appeal DB PK.
• Add a new filter field appeal_codes. It takes a list of appeal codes, split by commas.
• Replace the filter appeal_id with appeal_ids. It takes a list of Appeal DB PK, split by commas.
• Update API schema / generated types

[szabozoltan69]

I would be glad to keep appeal_id also for the use of appeal.id (so not Dref.id), as the numerical id of the related appeals.
But if it is hard, I can live without it. The minimal value of it is 3621, so no wonder that 6 or 26 gives nothing.

[thenav56]

I would be glad to keep appeal_id also for the use of appeal.id (so not Dref.id), as the numerical id of the related appeals. But if it is hard, I can live without it. The minimal value of it is 3621, so no wonder that 6 or 26 gives nothing.

It should be easy to add. Is this just for the filter, or for the response too?
We can add appeal_ids for filters and appeal_id in the response. Both look at appeal.id.

[szabozoltan69]

I would be glad to keep appeal_id also for the use of appeal.id (so not Dref.id), as the numerical id of the related appeals. But if it is hard, I can live without it. The minimal value of it is 3621, so no wonder that 6 or 26 gives nothing.

It should be easy to add. Is this just for the filter, or for the response too? We can add appeal_ids for filters and appeal_id in the response. Both look at appeal.id.

This would be the clearest way. We give what we say to give. (As filter and response also.)

[thenav56]

Super, I have updated the tasks in the description accordingly.