Fixing the 'Propose' Button Appearing for Users with Edit-Only Structured Property Permissions – DataHub Customer Support Portal

Area: Product Issues

Sub-Area: Permissions & Policy Configuration — Structured Properties

Issue

Administrators may observe that the Propose button on the Structured Properties tab of a dataset is visible and enabled for users whose group policies do not contain any explicit PROPOSE_* privilege. After querying the getGrantedPrivileges GraphQL endpoint and confirming the absence of proposal-specific privileges, it appears that the UI is incorrectly enabling the button. This leads to questions about whether the behavior is a UI bug, an intentional UX fallback, or a policy misconfiguration.

You Might Be Asking

Why is the Propose button enabled when my group has no PROPOSE_* privileges?
Is this a UI bug in DataHub?
How do I configure a group to have propose-only access without direct edit capability?
What happens behind the scenes when a user clicks the Propose button?
Can a custom validator plugin intercept structured property proposals?

Solution

Understanding the Intended Permission Hierarchy

This behavior is intentional and by design, not a UI bug. DataHub treats EDIT_ENTITY_PROPERTIES as a superset of propose privileges. The rationale is: if a user is authorized to directly write a value, they are inherently authorized to propose a change (which is a less privileged action). This logic is enforced in two places:

Frontend: useStructuredPropertyPermissions.ts — contains an explicit check where "canEdit implies ability to propose."
Backend: ProposalUtils.isAuthorizedToProposeStructuredPropertyUpdate() — applies the same superset logic server-side.

Step 1 — Verify Which Privileges Are Granted

Use the following GraphQL query to inspect the effective privileges for a given actor and resource:

query getGrantedPrivileges($input: GetGrantedPrivilegesInput!) {
  getGrantedPrivileges(input: $input) {
    privileges
  }
}

# Variables
{
  "input": {
    "actorUrn": "urn:li:corpGroup:<your-group-name>",
    "resourceSpec": {
      "resourceType": "DATASET",
      "resourceUrn": "urn:li:dataset:(urn:li:dataPlatform:<platform>,<dataset-name>,<env>)"
    }
  }
}

If the response includes EDIT_ENTITY_PROPERTIES or EDIT_DATASET_COL_PROPERTIES, the Propose button will be enabled — even without any PROPOSE_* privilege. This is the expected outcome.

Step 2 — Choose the Correct Policy Configuration for Your Use Case

Depending on your governance requirements, apply one of the following configurations:

Scenario A: Allow direct edit AND propose (current default when EDIT_ENTITY_PROPERTIES is granted)
No changes needed. Users with EDIT_ENTITY_PROPERTIES can both propose and directly apply changes.
Scenario B: Allow propose only, no direct edit
Remove EDIT_ENTITY_PROPERTIES from the group's policy and grant the appropriate propose privilege instead:
- For entity-level structured properties: grant PROPOSE_ENTITY_PROPERTIES and/or PROPOSE_ENTITY_PROPERTY_UPDATE
- For schema field (column-level) structured properties: grant the corresponding PROPOSE_DATASET_COL_* variants
Scenario C: No propose and no direct edit (view only)
Remove EDIT_ENTITY_PROPERTIES entirely and do not grant any PROPOSE_* privilege. Retain only view-scoped privileges such as VIEW_ENTITY and VIEW_METADATA_PROPOSALS.

Step 3 — Understanding the Proposal Workflow

When a user clicks Propose on the Structured Properties tab, the following happens:

DataHub creates a pending actionRequest entity that holds the proposed value. No change is applied to the asset at this point.
A reviewer with approval privileges reviews the pending proposal in the DataHub UI.
When the proposal is accepted, the request is marked as accepted and the proposed value is written to the asset in a separate step.
Both the proposal creation and the eventual value write go through DataHub's standard metadata write path.

Step 4 — Using a Custom Validator to Intercept Proposals (Advanced)

Because both the proposal write and the acceptance write use the standard metadata write path, a custom AspectPayloadValidator plugin (registered via entity-registry.yml) can hook into either step. No out-of-the-box validator specifically blocks structured property proposals. To implement custom validation logic:

# entity-registry.yml (example registration)
plugins:
  aspectPayloadValidators:
    - className: com.example.validators.MyStructuredPropertyValidator
      enabled: true

Your validator will be invoked during the standard write path and can reject either the proposal creation or the value being applied on acceptance.

Additional Notes

This permission hierarchy (EDIT_ENTITY_PROPERTIES superseding PROPOSE_*) applies to both entity-level structured properties and schema field (column-level) structured properties. The EDIT_DATASET_COL_PROPERTIES privilege similarly supersedes column-level propose privileges. This behavior is present in current versions of DataHub and is enforced consistently in both the frontend and backend. If your governance model requires strict separation between proposers and editors, configure the policies using the guidance in Step 2 above rather than relying solely on the absence of PROPOSE_* privileges.