# Unit Update Photo Handling Fix

## Problem

`PUT /api/units/{unit}` cannot accept multipart file uploads because PHP does not parse the multipart body for `PUT` requests. The server sees an empty body and the reused `UnitRequest` validation fails with "all fields required" (in particular `photos` is required).

The frontend currently works around this by sending `POST /api/units/{unit}` with `_method=PUT` and the multipart body. That workaround has two problems:

1. `routes/api.php` only registers `PUT /api/units/{unit}`, so the `POST` request never reaches `UnitController::update`.
2. Even if it did, `UnitRequest` still requires `photos`, so updates that only change scalar fields (or that keep existing photos) are rejected.

## Options Considered

### A. JSON `PUT` for fields + `POST /units/{id}/photos` for files

- Switch `UnitController::update` to a JSON-only `UnitUpdateRequest` with no `photos` field.
- Leave photo management to the already-existing `POST /api/units/{unit}/photos` endpoint.
- **Pros:** Clean REST contract; avoids the PHP PUT/multipart limitation entirely.
- **Cons:** Requires the frontend to split a single "save unit" action into two requests and to handle replacing vs. appending photos explicitly.

### B. Officially support `POST + _method=PUT` multipart and make photos optional on update

- Add a `POST /api/units/{unit}` route that dispatches to `UnitController::update`.
- Change `UnitController::update` to use `UnitUpdateRequest` with all scalar fields optional (`sometimes`) and `photos` optional.
- Keep the existing `replacePhotos()` behavior: only clear/replace the media collection when files are actually sent.
- **Pros:** Minimal frontend change (keeps the current `_method=PUT` form upload flow); fixes the validation bug; reuses the already-written `UnitUpdateRequest`.
- **Cons:** Less "pure REST" because updates can be sent as `POST` with method spoofing.

## Recommendation

**Option B.** It unblocks the frontend's current flow immediately, fixes the root cause (validation + routing), and keeps the API surface small. The existing `UnitUpdateRequest` was already created for exactly this purpose; it only needs `photos` and a couple of other fields added.

## Root-Cause Detail

Two independent bugs combined to produce the reported error:

1. **Routing/validation:** `PUT /api/units/{unit}` reused `UnitRequest`, which requires `photos` and many other fields, so any update without a complete payload failed validation.
2. **File detection in the update handler:** `replacePhotos()` used `$request->hasFile('photos')`. For the nested file structure `photos[n][photo]`, `hasFile('photos')` returns `false` even when files are present, so the controller silently skipped clearing/storing photos.

## Implementation

1. `routes/api.php`: add `Route::post('units/{unit}', [UnitController::class, 'update']);` after the existing `PUT` route.
2. `app/Http/Controllers/UnitController.php`:
   - Change `update(UnitRequest $request, Unit $unit)` to `update(UnitUpdateRequest $request, Unit $unit)`.
   - Change `replacePhotos()` to use `empty($request->file('photos'))` instead of `!$request->hasFile('photos')` so nested files are detected.
   - Keep `$unit->update($request->safe()->except(['photos']))` and `$this->replacePhotos($unit, $request)`.
3. `app/Http/Requests/UnitUpdateRequest.php`:
   - Add `building_id` as `sometimes|exists:buildings,id`.
   - Add `rooms` as `sometimes|integer|min:1`.
   - Add `photos` as `sometimes|nullable|array`.
   - Add `photos.*.photo` as `required|image|mimes:jpg,jpeg,png|max:10240`.
   - Add `booking conditions` as `sometimes|nullable|json` (matching the existing request key used by `UnitRequest`).
   - Keep the existing `slug` rule with `Rule::unique(...)->ignore($this->route('unit'))`.
4. `api.json`: updated the `/api/units/{unit}` entry to document both `PUT` (JSON, fields optional, no photos) and `POST` (multipart, fields optional, photos optional).
5. Tests: add `tests/Feature/UnitUpdatePhotoTest.php` proving:
   - `POST /api/units/{unit}` with `_method=PUT` and no `photos` keeps existing media.
   - The same endpoint with new photos clears old media and stores the new ones.
   - Native `PUT /api/units/{unit}` with only JSON still works for scalar updates.
   - Invalid photo files are rejected.

## Out of Scope

- Building photo handling uses the same `replacePhotos()` pattern and has the same `hasFile` bug, but this change focuses on units only. Building can be fixed with an identical follow-up if needed.
- Adding base64 image support.
- Renaming the `documents` media collection.