Fix:Opportunity statuses #332

[lourooo]

Fix: Opportunity statuses #332

Description

Add a status change modal for opportunities, similar to the volunteer engagement status. Since the backend does not yet support the new statuses, fake data is used for the 4 new ones, they update the UI only and do not send a request to the backend.

Related Issues

Closes #332

Changes

• Created ChangeOpportunityStatusDialog, modal with radio buttons following the volunteer status pattern
• Created useOpportunityStatusDialog, hook to manage modal state and API calls
• Created OpportunityManualStatusType, enum with all 6 statuses (New, Searching, Cancelled by us, Cancelled by NGO, Matched - not needed, Matched - volunteer no show)
• Updated OpportunityHeader to use the new dialog
• Added color and icon mappings for the new statuses in statusMaps.ts
• Added translations in EN and DE

Screenshots / Demos

Checklist

• WITHIN THE SCOPE OF AN ISSUE; No unnecessary files included
• Tests added/updated
• Documentation updated
• CI passes

[need4deed]

@lourooo in the text change the explorations :
"The opportunity was not validated yet
The opportunity was validated it can be searched for
The opportunity was cancelled - no volunteer found
The opportunity was cancelled - by NGO
A volunteer was matched but at the last minute not needed
A volunteer was matched but did not show up"

Reminder: that there are other statuses that are automatic not manual so they will appear on the status but not the manual menu e.g. once somene is "matched" - matched

[lourooo]

Updated

[Cy-fox]

Everything looks nice, he:

• reuses useStatusDialog and ChangeStatusDialog from common/ consistent with the pattern used for volunteers.
• Clean separation of concerns: hook / component / constants.

In my knowledge looks normal

[need4deed]

check this two points

1. OpportunityManualStatusType.NEW and SEARCHING missing from statusColorMap and statusIconMap : constants.ts defines these as "opp-new" and "opp-searching", but in statusMaps.ts the existing

OpportunityStatusType.NEW and OpportunityStatusType.SEARCHING handle the old SDK values. The new manual values opp-new / opp-searching are not in the maps, so the status badge will have no color and no
icon when those are selected.

2. OpportunityHeader reads dialog.selected (manual type) but StatusRowField may expect the SDK type: the status displayed in the header is now always a OpportunityManualStatusType value. If

[lourooo]

Updated

[nadavosa]

Before this gets merged, please run yarn lint and yarn typecheck locally and fix any errors. We've added a CI check (#359) that will block merging if these fail.

[lourooo]

Everything is fine

[need4deed]

@lourooo we had some changes from our side: we dont need all the new ones there (we will add it to a section so keep the code somewhere)

The selection should be:
New / Needs validation
Searching
Inactive

[lourooo]

Okok

[lourooo]

Updated!

[nadavosa]

Review

No new BE endpoints needed — uses the existing useUpdateOpportunityStatus hook throughout. Good on that front.

The dialog approach is a clear improvement over the hardcoded single-step button. Two issues to fix before merging:

---

1. OpportunityStatusType.ACTIVE is not mapped in SDK_TO_MANUAL

export const SDK_TO_MANUAL: Partial<Record<OpportunityStatusType, OpportunityManualStatusType>> = {
  [OpportunityStatusType.NEW]: OpportunityManualStatusType.NEW,
  [OpportunityStatusType.SEARCHING]: OpportunityManualStatusType.SEARCHING,
  // ACTIVE and PAST are missing
};

toManualStatus falls back to OpportunityManualStatusType.NEW for anything not in the map — so an opportunity with ACTIVE status will display as "New / Needs validation" in the header. Either add ACTIVE as a manual status option or map it to the closest equivalent.

---

2. Type safety regression in statusColorMap / statusIconMap

Switching from typed object literals to Object.fromEntries() as unknown as Record<StatusValue, T> loses exhaustiveness checking. If a new StatusValue is added, TypeScript won't warn it is missing from these maps. The as unknown cast is a red flag here.

Keep the original typed Record<StatusValue, T> object literal and just add the OpportunityManualStatusType entries to it — that is all that is needed.

---

Also needs a rebase to resolve conflicts with develop before merging.

[lourooo]

Updated

[nadavosa]

Once SDK issue need4deed-org/sdk#87 and BE migration need4deed-org/be#412 are merged, update this PR:

In `constants.ts`, change `MANUAL_TO_SDK`:
```ts
// Before (workaround):
[OpportunityManualStatusType.INACTIVE]: OpportunityStatusType.PAST,

// After:
[OpportunityManualStatusType.INACTIVE]: OpportunityStatusType.INACTIVE,
```

That's the only change needed — the modal, hook, and translations are already correct.

[lourooo]

Updated

[nadavosa]

All three issues addressed:

1. SDK_TO_MANUAL now covers ACTIVE (→ SEARCHING) and INACTIVE (→ INACTIVE) — no more fallback to NEW for active opportunities
2. statusColorMap/statusIconMap refactored to typed spread approach — manualStatusColorMap/manualStatusIconMap use proper Record<OpportunityManualStatusType, ...> which preserves exhaustiveness checking
3. SDK bumped to 0.0.78 which adds INACTIVE

One thing remaining before merge: the PR needs a rebase to resolve conflicts with develop.