MT-23488: fix bulk permissions request body field names - #151
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe permission update API now accepts boolean ChangesPermission update payload
Estimated code review effort: 2 (Simple) | ~10 minutes Mergeability Score: ⚪ Minimal · up to This localized request-body fix is merge-ready after normal checks; no actionable merge-blocking risk remains, with only a follow-up to confirm the in-app example matches the updated boolean parameter. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Motivation
MT-23488
permissions.bulkPermissionsUpdatedidn't work at all. The request body was built withresourceTypeandaccessLevelkeys, but the API expectsresource_typeandaccess_level. Rails strong params drop unknown keys, so the API ignored the update. Destroy was broken too:_destroywas only sent when the caller passed an untyped_destroyfield (hidden behind a@ts-ignore), and the typeddestroyparam did nothing.Changes
resource_typeandaccess_levelinstead of the camelCase keys inPUT .../permissions/bulk_destroyfrom the typeddestroyparam, drop the@ts-ignorethat was hiding the bugdestroyfromstringtobooleanto match_destroy: booleanin the OpenAPI spec. With a string,destroy: "false"would still destroy the permission on the server; with a boolean,falsesimply isn't sentHow to test
permissions.bulkPermissionsUpdate(accessId, [{ resourceId, resourceType: "account", accessLevel: "viewer" }])– the permission is created/updated with viewer access. Before the fix the API dropped the camelCase keys and nothing changeddestroy: true– the permission is destroyed. Before the fix the destroy flag never reached the APIdestroy: false– the permission is created/updated, not destroyedpermissions.getResources()– still works as beforeCaveat:
destroyinPermissionResourceParamschanges fromstringtoboolean. Nobody can depend on the old type –_destroynever reached the API before this fix.Summary by CodeRabbit
Bug Fixes
Tests