This commit addresses two critical issues with Docker Compose service management:
## Issue 1: Duplicate Services Created on Image Change
When changing the image in a docker-compose file, the parser was creating new
ServiceApplication/ServiceDatabase records instead of updating existing ones.
**Root Cause**: The parsers used `firstOrCreate()` with `['name', 'image', 'service_id']`,
meaning any image change would create a new record.
**Fix**: Remove `image` from `firstOrCreate()` queries and update it separately after
finding or creating the service record.
**Changes**:
- `bootstrap/helpers/parsers.php` (serviceParser v3): Fixed in presave loop (lines 1188-1203)
and main parsing loop (lines 1519-1539)
- `bootstrap/helpers/shared.php` (parseDockerComposeFile v2): Fixed null check logic
(lines 1308-1348)
## Issue 2: UI Not Refreshing After Changes
When compose file or domain was modified, the Configuration component wasn't receiving
events to refresh its data, requiring manual page refresh to see updates.
**Root Cause**: The Configuration component wasn't listening for refresh events dispatched
by child components (StackForm, EditDomain).
**Fix**: Add event listeners and dispatchers to enable real-time UI updates.
**Changes**:
- `app/Livewire/Project/Service/Configuration.php`: Added listeners for `refreshServices`
and `refresh` events (lines 36-37)
- `app/Livewire/Project/Service/EditDomain.php`: Added `refreshServices` dispatch (line 76)
- Note: `app/Livewire/Project/Service/StackForm.php` already had the dispatch
## Tests Added
- `tests/Unit/ServiceParserImageUpdateTest.php`: 4 tests verifying no duplicates created
- `tests/Unit/ServiceConfigurationRefreshTest.php`: 4 tests verifying event dispatching
All 8 new tests pass, and all existing unit tests continue to pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Introduced `isReadOnlyVolume` method in `LocalFileVolume` and `LocalPersistentVolume` models to determine if a volume is read-only based on Docker Compose configuration.
- Updated `FileStorage` and `Show` components to set `isReadOnly` state during mounting.
- Enhanced UI to display notifications for read-only volumes, preventing modification actions in the interface.
- Refactored file storage and directory management forms to conditionally enable or disable actions based on read-only status.
- Merged the storage management functionalities into the Storage component, replacing the previous Add component.
- Introduced new methods for submitting persistent volumes, file mounts, and directory mounts, improving code organization and maintainability.
- Enhanced the UI with modals for adding volumes, files, and directories, providing a more intuitive user experience.
- Updated validation rules and error handling for improved robustness during storage submissions.
- Removed deprecated Add component and associated views to streamline the codebase.
- Added properties to manage file and directory counts, improving data handling in the Livewire component.
- Updated the file storage view to include a tabbed interface for volumes, files, and directories, enhancing user navigation.
- Improved UI layout for better readability and user experience, including consistent styling and informative messages.
- Introduced `ValidationPatterns` class to standardize validation rules and messages for various fields across multiple components.
- Updated components including `General`, `StackForm`, `Create`, and `Show` to utilize the new validation patterns, ensuring consistent validation logic.
- Enhanced error messages for required fields and added regex validation for names and descriptions to improve user feedback.
- Adjusted styling in the `create.blade.php` view for better visual hierarchy.
Added a new delete method in the Database component that includes a two-step confirmation process requiring the user to enter their password. If two-step confirmation is disabled, the deletion proceeds without password verification. Additionally, a confirmation modal has been integrated into the database view to prompt users before deletion, enhancing the safety of this critical operation.
- Introduced `environment_uuid` as a required field in various API endpoints and schemas.
- Updated descriptions to clarify that either `environment_name` or `environment_uuid` must be provided.
- Modified routes and controller methods to accommodate the new UUID parameter.
- Adjusted frontend components to utilize `environment_uuid` for better consistency and clarity.
- Removed deprecated fields related to environment handling.
This change enhances the API's flexibility in identifying environments, improving overall usability.