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)
nolanpro
changed the title
| $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)
| public function update(Request $request, $clientId) | ||
| { | ||
| $client = $this->clients->find($clientId); | ||
| $client = $this->clients->findForUser($clientId, $request->user()); |
There was a problem hiding this comment.
OAuth client update/destroy restricted to owner only
Medium Severity
The update and destroy methods changed from $this->clients->find($clientId) to $this->clients->findForUser($clientId, $request->user()). This restricts operations to only clients owned by the requesting user, while the index method still returns ALL clients. Users with edit-auth_clients or delete-auth_clients permissions will see clients in the list but receive 404 errors when attempting to modify clients they don't own, breaking admin management functionality.
Additional Locations (1)
| /** | ||
| * Store a new client. | ||
| * | ||
| * @param \Illuminate\Http\Request $request |
There was a problem hiding this comment.
Duplicated type-extraction logic in store and update methods
Low Severity
The store() and update() methods contain identical code for extracting $personalAccess, $password, and $redirect from $request->types. These three lines are duplicated verbatim between the two methods. This logic could be extracted to a private helper method like parseClientTypes(Request $request) to reduce duplication and make future maintenance easier.
Additional Locations (1)
|
QA server K8S was successfully deployed https://ci-9fdd0aafa1.engk8s.processmaker.net |
3 similar comments
|
QA server K8S was successfully deployed https://ci-9fdd0aafa1.engk8s.processmaker.net |
|
QA server K8S was successfully deployed https://ci-9fdd0aafa1.engk8s.processmaker.net |
|
QA server K8S was successfully deployed https://ci-9fdd0aafa1.engk8s.processmaker.net |
|
QA server K8S was successfully deployed https://ci-9fdd0aafa1.engk8s.processmaker.net |
AugustoLopezProcess
left a comment
AugustoLopezProcess
left a comment
There was a problem hiding this comment.
Looks good to me.
Since this branch touches a fairly broad surface area (framework/bootstrap/middleware, Passport, auth flows, and other product changes), I’d suggest treating QA as the main gate here. A regression-style smoke test would be helpful
In particular, it would be great to confirm the following:
- Web login and session behavior (including cases where a user becomes BLOCKED or INACTIVE after login)
- API calls using a standard user token
- Forgot password and reset flows for ACTIVE vs BLOCKED/INACTIVE users (ensuring restricted users don’t get a usable reset path)
|
4 participants
Needs these too:
https://github.com/ProcessMaker/.github/tree/testbench
Change .github/workflows/deploy-pm4.yml back when merged
https://github.com/ProcessMaker/pm4-k8s-distribution/tree/2026-7-php85
ci:k8s-branch:2026-7-php85
ci:connector-idp:feature/FOUR-30092
ci:connector-pdf-print:feature/FOUR-30092
ci:connector-send-email:feature/FOUR-30092
ci:connector-slack:feature/FOUR-30092
ci:docker-executor-node-ssr:feature/FOUR-30092
ci:modeler:feature/FOUR-30092
ci:package-ab-testing:feature/FOUR-30092
ci:package-actions-by-email:task/FOUR-28803
ci:package-ai:task/FOUR-28803
ci:package-analytics-reporting:task/FOUR-28803
ci:package-api-testing:feature/FOUR-30092
ci:package-auth:task/FOUR-28803
ci:package-collections:task/FOUR-28803
ci:package-comments:feature/FOUR-30092
ci:package-conversational-forms:feature/FOUR-30092
ci:package-decision-engine:task/FOUR-28803
ci:package-email-start-event:task/FOUR-28803
ci:package-photo-video:feature/FOUR-30092
ci:package-pm-blocks:feature/FOUR-30092
ci:package-savedsearch:task/FOUR-28803
ci:package-signature:feature/FOUR-30092
ci:package-smart-extract:task/FOUR-28803
ci:pm4-api-testing:feature/FOUR-30092
ci:screen-builder:feature/FOUR-30092
ci:vue-multiselect:feature/FOUR-30092
ci:deploy
ci:use-packagist-branches
ci:run-testbench