Skip to content

v1.2.5

Choose a tag to compare

View all tags
@mpge mpge released this 07 May 14:22
· 49 commits to main since this release
v1.2.5
0389bc5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

Resolves the install failure reported in #88 for real this time (#92)

The actual underlying issue (surfaced thanks to verbose migrate output): MariaDB and older MySQL versions reject escalated_macros's foreign key to users(id) with errno: 150 "Foreign key constraint is incorrectly formed" whenever the host app's users table doesn't exactly match what we expect. Reproduced on MariaDB 11 under four common host configurations:

  • users table on MyISAM (legacy Laragon / WAMP default_storage_engine=MyISAM)
  • users.id is signed BIGINT (project upgraded from Laravel pre-5.8)
  • users.id is INT UNSIGNED (project from pre-5.8 increments())
  • users.id is CHAR(36) UUID (custom user model with HasUuids)

We can't control any of those four from a package, so this release drops the foreign-key constraints from the five migrations that pointed at the host's users table:

  • escalated_macros.created_by
  • escalated_ticket_followers.user_id
  • escalated_saved_views.user_id
  • escalated_mentions.user_id
  • escalated_tickets.snoozed_by

Each becomes a plain unsignedBigInteger column. Foreign keys to our own tables (e.g. escalated_tickets) stay — those always work because we own both sides.

This is the same pattern spatie/laravel-permission, spatie/laravel-activitylog, and Filament use for the same reason.

Better diagnostics on install (#91)

escalated:install was using callSilently('migrate') wrapped in a task component, which swallowed Laravel's actual SQL error and just printed FAIL. Now it prints the full migrate output (per-migration timing, failing migration name, full PDO/SQL error). Same treatment for db:seed. Took a back-and-forth with the reporter to get the real error before — won't happen again.

Backwards compatibility

Forward-compatible only. Anyone with a successful prior install keeps their existing FK constraints because Laravel doesn't re-run migrations once recorded. Anyone hit by #88 sees migrations 14+ run cleanly on their next php artisan migrate.

If a host app hard-deletes users, orphaned created_by / user_id rows in our tables won't be cascade-cleaned anymore (most apps soft-delete users so this is a non-issue in practice). If you need cleanup, attach a User-deleting model observer in the host app.

Upgrade

composer update escalated-dev/escalated-laravel
php artisan escalated:install

Full Changelog: v1.2.4...v1.2.5

Assets 2
Loading