Upgrade to Laravel 12 and PHP 8.4 #8687
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| $views = array_map(function ($item) { | ||
| return $item['name']; | ||
| }, Schema::getViews()); | ||
| }, Schema::getViews($database)); |
There was a problem hiding this comment.
getViews returns incompatible data structure breaking view logic
High Severity
The getViews() method now returns a numerically-indexed array of view name strings, but consumers expect an associative array keyed by view name with objects having a getSql() method. In shouldCreate(), the check isset($views[$viewName]) will always fail since the array uses numeric keys, causing views to always be recreated unnecessarily. In the up() method's foreach loop, $viewName becomes numeric indices (0, 1, 2...) instead of actual view names, breaking the dropped table detection logic entirely.
Additional Locations (2)
| true, // confidential | ||
| $request->user() | ||
| ); | ||
| } |
There was a problem hiding this comment.
Store method silently ignores multiple selected client types
Medium Severity
The store() method uses an if-elseif-else structure that only creates one client type, silently ignoring additional types when multiple are selected. The validation allows multiple types (array|min:1), and the update() method correctly handles both personal_access_client and password_client flags independently. However, store() only honors the first matching type—if both personal access and password are requested, only the personal access client is created. This creates an inconsistency where capabilities available via update are not available during creation.
nolanpro
changed the title
| $tables = array_map(function ($item) { | ||
| return $item['name']; | ||
| }, Schema::getTables()); | ||
| }, Schema::getTables($database)); |
There was a problem hiding this comment.
Schema methods don't accept database parameter
High Severity
Schema::getTables() and Schema::getViews() methods in Laravel 12 don't accept a database name parameter. The code passes $database to these methods, but they take no arguments. This would cause an ArgumentCountError at runtime when the processmaker:create-data-lake-views artisan command is executed.
Additional Locations (1)
| $request->name, | ||
| null, // provider | ||
| false // confidential | ||
| ); |
There was a problem hiding this comment.
OAuth clients not associated with user when created
High Severity
When creating personal access or password grant clients via store(), the new code uses createPersonalAccessGrantClient() and createPasswordGrantClient() which don't associate the client with the authenticated user. The old code passed $request->user()->getKey() to link all client types to the user. Since show(), update(), and destroy() all use findForUser($clientId, $request->user()) to retrieve clients, users can no longer access, modify, or delete personal access and password grant clients they create through this API.
Additional Locations (2)
| $request->name, | ||
| null, // provider | ||
| false // confidential | ||
| ); |
There was a problem hiding this comment.
Password grant client created as non-confidential breaks database
High Severity
The createPasswordGrantClient() call passes false for the confidential parameter, but the oauth_clients database table has a NOT NULL constraint on the secret column. Non-confidential clients don't receive a secret, which will cause a database constraint violation. The UserSeeder explicitly uses true with a comment explaining "must be true as database requires secret to be NOT NULL", but the controller uses the opposite value.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| if (!$client) { | ||
| $clientRepository = app('Laravel\Passport\ClientRepository'); | ||
| $client = $clientRepository->create(null, 'devlink', $redirectUri); | ||
| $client = $clientRepository->createAuthorizationCodeGrantClient('devlink', [$redirectUri]); |
There was a problem hiding this comment.
DevLink client creation missing confidential parameter
Medium Severity
The createAuthorizationCodeGrantClient call in DevLinkController doesn't pass the confidential parameter, relying on its default value. The old create() method defaulted confidential to true. Elsewhere in the codebase (ClientController.store() and UserSeeder), this parameter is explicitly passed as true with comments noting the database requires a non-null secret. If the new method's default differs, this could cause database constraint violations or create clients with null secrets that break the OAuth flow when $client->secret is used on line 52.
|
ci:k8s-branch:2026-3-php84
ci:package-auth:task/FOUR-28803
ci:package-email-start-event:task/FOUR-28803
ci:package-collections:task/FOUR-28803
ci:package-actions-by-email:task/FOUR-28803
ci:pmql:task/FOUR-28803
...........
Note
Major framework/runtime upgrade with Passport API adaptations and related refactors.
php@8.4,laravel/framework@^12,laravel/passport@^13, and other deps (JWT, PSR, Swagger, Kafka, TNTSearch, OpenAI, PMQL, etc.)AuthServiceProvider), switch to newClientRepositoryAPIs (createAuthorizationCodeGrantClient,createPersonalAccessGrantClient,createPasswordGrantClient), usefindForUserfor client lookups, and passUsermodel to token lookups (TokenRepository::forUser/findForUser).UserTokenResourceto normalize responses forPersonalAccessTokenResultandTokenmodels; updateUserTokenControlleraccordingly.oauth_device_codes(device flow table).AuthenticateSessionto run only onSessionGuard; removemiddlewarePriorityfromKernel.Schema::getTables/getViewsby database;BuildScriptExecutortriesreduced to 1.CreateTestDBscommand; add.envrcto.gitignore.Written by Cursor Bugbot for commit 48065d0. This will update automatically on new commits. Configure here.