# Test Scenario Guide: Cost Estimate Material Validation Fix

### 2. Scenario Introduction
When updating resources (materials) for a cost estimate phase, the system validates the `material_id`. Previously, this validation failed for valid materials because it checked the database without applying tenant scoping (Company Scope) or checking for soft-deleted records. This fix ensures that `material_id` validation resolves within the active tenant's scope and ensures the material is active (not deleted). This maintains robust multi-tenant data integrity and prevents cross-company data assignment.

### 3. Technical Schema Changes (Detailed) 🔍

* **Endpoint:** `POST /resources-item/update` and `POST /resources-item/store`
* **Validation Changes:** 
    * Field `materials.*.material_id` (and `materials.*.id` in store request) changed from a generic `Rule::exists('materials', 'id')` to a scoped Eloquent rule using `Material::class`.
    * Added `->where('company_id', company()->id)` to enforce tenant isolation.
    * Added `->whereNull('deleted_at')` to prevent the use of soft-deleted materials.
* **Response Changes:** 
    * No change to response structure.

### 4. Why the Update? (Change Log) 🔄
* **Previous Behavior:** The validation returned a `422 Unprocessable Entity` error ("The selected materials.0.material_id is invalid") even for valid materials within the company because the basic `exists` rule queried the table directly without the necessary tenant and active status scopes.
* **New Behavior:** The validation now successfully accepts valid `material_id`s that belong to the active company and are not soft-deleted.
* **Benefits:**
    * **Data integrity**: Prevents cross-tenant material assignment.
    * **User Experience**: Fixes a false-positive validation error that blocked cost estimate updates.
    * **Improved security**: Restricts data access strictly to the authenticated company.

### 5. API Endpoints Table 📊
| Process | Endpoint | Method | Description |
| :--- | :--- | :--- | :--- |
| Store Resource Item | `/api/v1/resources-item/store` | `POST` | Creates new resource items including materials for a cost estimate phase |
| Update Resource Item | `/api/v1/resources-item/update` | `POST` | Updates existing resource items including materials |

### 6. Test Cases 🧪

* **[Case 1] The Happy Path:** 
    * Send a request to `POST /resources-item/update` with a valid `material_id` belonging to the current `company_id`.
    * **Expected:** The request succeeds with a `200 OK` status and updates the materials.
* **[Case 2] Backward Compatibility:** 
    * Existing materials updated without changing the `material_id` should still pass validation as long as they belong to the current company.
* **[Case 3] Edge Cases & Constraints:** 
    * **Cross-tenant attempt:** Send a `material_id` that belongs to a *different* company.
        * **Expected:** Returns `422 Unprocessable Entity` for `material_id`.
    * **Soft-deleted material:** Send a `material_id` that has been soft-deleted (`deleted_at` is not null).
        * **Expected:** Returns `422 Unprocessable Entity` for `material_id`.
    * **Invalid ID:** Send a completely non-existent `material_id`.
        * **Expected:** Returns `422 Unprocessable Entity` for `material_id`.