Changes:
1. Remove description field from cloud-init scripts
- Updated migration to remove description column
- Updated model to remove description from fillable array
2. Redesign script name input layout
- Move script name input next to checkbox (always visible)
- Remove conditional rendering - input always shown
- Use placeholder instead of label for cleaner look
3. Fix dropdown type error
- Replace wire:change event with wire:model.live
- Use updatedSelectedCloudInitScriptId() lifecycle hook
- Add "disabled" attribute to placeholder option
- Properly handle empty string vs null in type casting
4. Improve validation
- Require both script content AND name for saving
- Remove description validation rule
- Add selected_cloud_init_script_id validation
5. Auto-populate name when loading saved script
- When user selects saved script, auto-fill the name field
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit adds the ability to use cloud-init scripts when creating Hetzner servers through the integration. Users can write custom scripts that will be executed during server initialization, and optionally save these scripts at the team level for future reuse.
Key features:
- Textarea field for entering cloud-init scripts (bash or cloud-config YAML)
- Checkbox to save scripts for later use at team level
- Dropdown to load previously saved scripts
- Scripts are encrypted in the database
- Full validation and authorization checks
- Comprehensive unit and feature tests
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Introduced a new notification class, BackupSuccessWithS3Warning, to alert users when local backups succeed but S3 uploads fail.
- Updated DatabaseBackupJob to track local backup success and handle S3 upload errors, improving error reporting and user notifications.
- Modified ScheduledDatabaseBackupExecution model to include a new s3_uploaded boolean field for tracking S3 upload status.
- Adjusted views and validation logic to reflect changes in backup execution status and S3 handling.
- Added tests to ensure the new s3_uploaded column is correctly implemented and validated.
- Introduced a new boolean setting `is_git_shallow_clone_enabled` to the application settings model.
- Updated the `Advanced` component to include a checkbox for enabling shallow cloning.
- Modified the `setGitImportSettings` and `generateGitImportCommands` methods to handle shallow clone logic.
- Created a migration to add the new setting to the database schema.
- Enhanced the deployment process to utilize shallow cloning for improved performance.
- Added functionality for users to request an email change, including generating a verification code and setting an expiration time.
- Implemented methods in the User model to handle email change requests, code validation, and confirmation.
- Created a new job to update the user's email in Stripe after confirmation.
- Introduced rate limiting for email change requests and verification attempts to prevent abuse.
- Added a new notification for email change verification.
- Updated the profile component to manage email change requests and verification UI.
- Added a new job, ServerPatchCheckJob, to handle server patch checks and notifications.
- Introduced a new notification class, ServerPatchCheck, for sending updates via email, Discord, Slack, Pushover, and Telegram.
- Updated notification settings models to include server patch notification options for email, Discord, Slack, Pushover, and Telegram.
- Created a migration to add server patch notification fields to the respective settings tables.
- Enhanced the UI to allow users to enable/disable server patch notifications across different channels.
- If you set a low local backup retention, for example 2 backups for local backup retention and 10 backups for S3, then the S3 backups were never deleted, not even after 10 days. This was because we check the file paths based on the backup executions table, and as soon as a backup was deleted locally, the execution was removed, which meant after 10 days for s3 there where no backups older then 10 days just the 2 local backups which is just wrong. Now we only delete a backup execution if it has been removed from both locations.
- Also added a nice little UI element to see where your backup is available.
