fix: show objects that only support field permissions - #1982
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes missing Salesforce objects in the Manage Permissions object picker by treating object CRUD permissions (ObjectPermissions.SobjectType) and field-level security (FieldPermissions.SobjectType) as independent allow-lists and showing their union. It also updates the object-permissions UI to render objects with no ObjectPermissions support as read-only, matching Salesforce behavior and preventing invalid saves.
Changes:
- Build the permissionable object picker list from the union of
ObjectPermissions.SobjectTypeandFieldPermissions.SobjectType. - Add per-object support flags (
supportsObjectPermissions/allowObjectPermission) and render unsupported objects read-only in the Object Permissions table. - Add/adjust Vitest coverage for the new support flags and picker filtering behavior.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| libs/types/src/lib/ui/permission-manager-types.ts | Adds supportsObjectPermissions and allowObjectPermission flags to drive read-only rendering. |
| libs/features/manage-permissions/src/utils/permission-manager-utils.ts | Introduces dual allow-list loading and updates the object filter to use the union set. |
| libs/features/manage-permissions/src/utils/permission-manager-table-utils.tsx | Greys out unsupported objects and suppresses object CRUD cell editing/rendering for field-only objects. |
| libs/features/manage-permissions/src/utils/object-permission-support.ts | Adds the user-facing message shown for objects that can’t accept ObjectPermissions. |
| libs/features/manage-permissions/src/utils/tests/permission-manager-view-all-modify-all.spec.ts | Updates test builders to include the new supportsObjectPermissions / allowObjectPermission fields. |
| libs/features/manage-permissions/src/utils/tests/permission-manager-table-label-column.spec.ts | Updates object-row test builder to include allowObjectPermission. |
| libs/features/manage-permissions/src/utils/tests/permission-manager-sobject-filter.spec.ts | Updates allow-list mocking and asserts union behavior for the object picker. |
| libs/features/manage-permissions/src/utils/tests/permission-manager-object-permission-support.spec.ts | Adds tests for allowObjectPermission propagation and per-cell editability/label styling. |
| libs/features/manage-permissions/src/usePermissionRecords.tsx | Loads ObjectPermissions describe to identify objects that should be read-only for object CRUD. |
| libs/features/manage-permissions/src/usePermissionableSobjects.ts | Updates hook state typing to the new PermissionableSobjects shape. |
| libs/features/manage-permissions/src/ManagePermissionsSelection.tsx | Updates UI commentary to reflect the new union allow-list and read-only behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A user reported that Price Book Entry was missing from the object list in manage permissions even though Salesforce offers it for field level security. It was not alone - 43 objects were unreachable, including Task, Event, Opportunity Product, Order Product and User. Salesforce keeps two independent allow-lists and neither is a subset of the other. ObjectPermissions.SobjectType covers object CRUD and omits any object whose record access rolls up to a parent, while FieldPermissions.SobjectType covers field level security and includes those children. We only read the first one, and it gated the object picker for all four tabs, so an object with no ObjectPermissions record vanished from the field and tab visibility tabs too. The picker now shows the union of both. FieldPermissions.Field would be the narrower signal - it identifies the 15 of those 43 that actually expose a settable field - but filtering on it would hide the rest entirely and diverge from Salesforce's own object list. Objects such as Price Book Entry are kept even though their field tab comes up empty, because tab visibility may still apply and we expect to add more per-object settings here later. Objects with no ObjectPermissions record now render read-only on the object permissions tab rather than offering checkboxes that fail on save with INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST. This follows the existing treatment for objects without a tab and for View All / Modify All where Salesforce silently drops the value. Also removes a stray console.log left behind in filterPermissionsSobjects.
8a7f703 to
5a0633d
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.
Suppressed comments (1)
libs/features/manage-permissions/src/usePermissionRecords.tsx:79
describeSObject(selectedOrg, 'ObjectPermissions')is added into the mainPromise.allload pipeline. If that describe call rejects (transient network error, org/session mismatch, permissions, etc.), it will now reject the entirefetchMetadata()and fliphasErrorto true — even though this describe is only used to compute the read-only UX flag and the rest of the permission data could still load.
Consider swallowing failures for this specific describe and treating it as “unknown allow-list” (i.e., empty picklist/fields) so the page remains usable and objects default to supportsObjectPermissions: true when the allow-list can’t be determined.
const output = await Promise.all([
limit(() => describeSObject(selectedOrg, 'FieldPermissions')),
// Cached from the object picker - identifies objects with no ObjectPermissions record (PricebookEntry, Task, ...)
limit(() => describeSObject(selectedOrg, 'ObjectPermissions')),
queryPermissionableFields(limit, selectedOrg, sobjects),
A user reported that Price Book Entry was missing from the object list in manage permissions even though Salesforce offers it for field level security. It was not alone - 43 objects were unreachable, including Task, Event, Opportunity Product, Order Product and User.
Salesforce keeps two independent allow-lists and neither is a subset of the other. ObjectPermissions.SobjectType covers object CRUD and omits any object whose record access rolls up to a parent, while FieldPermissions.SobjectType covers field level security and includes those children. We only read the first one, and it gated the object picker for all four tabs, so an object with no ObjectPermissions record vanished from the field and tab visibility tabs too. The picker now shows the union of both.
FieldPermissions.Field would be the narrower signal - it identifies the 15 of those 43 that actually expose a settable field - but filtering on it would hide the rest entirely and diverge from Salesforce's own object list. Objects such as Price Book Entry are kept even though their field tab comes up empty, because tab visibility may still apply and we expect to add more per-object settings here later.
Objects with no ObjectPermissions record now render read-only on the object permissions tab rather than offering checkboxes that fail on save with INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST. This follows the existing treatment for objects without a tab and for View All / Modify All where Salesforce silently drops the value.
Also removes a stray console.log left behind in filterPermissionsSobjects.
Resolves #1981