How to grant a non-admin role the ability to create custom SQL tests and test-suite pipelines?

[SMZiminRu]

How to grant a non-admin role the ability to create custom SQL tests and test-suite pipelines?

Environment

• OpenMetadata version: 1.12.3.0
• Auth: local users + policies in Settings → Access Control
• Database: PostgreSQL

What we want

We need a role — call it "Data Quality Author" — that lets a group of data
engineers do their job without being admins:

1. Create and edit custom SQL test definitions in the Test Library
2. Create test cases from those definitions on any table
3. Create and schedule test-suite ingestion pipelines

They must not get admin: no user/role/policy management, no service
credentials, no Impersonate, no GenerateToken.

Today Test Library is documented as admin-only, so point 1 already looks
impossible. But even points 2 and 3 do not work for us.

What happens

We granted all permissions on Test Suites (and TestCase) to a custom role
and assigned it to a test user. The user can open the table, go to
Data Quality, click Add Test — but the test type selection is empty.
No custom SQL tests, no built-in tests, nothing to pick.

The same user works fine if we make them an admin.

What we suspect

This looks like #29542, which was reported against 1.12.6:

GET /api/v1/dataQuality/testDefinitions?entityType=Column&... returns 0
results, while ?entityType=COLUMN returns the full set. Admins bypass it
because isAdmin() short-circuits authorization.

That issue was fixed by #31141 on main, but I could not find a backport to
the 1.12 line, and we are on 1.12.3.0.

The workaround reported there — grant testDefinition: All instead of
ViewAll — is worth confirming, because we only granted permissions on the
Test Suite / Test Case resources and never on Test Definition.
Three separate resources is easy to miss.

Questions

1. Is the correct permission set for a non-admin DQ author:

   • TestDefinition: All
   • TestCase: Create + EditAll
   • TestSuite: Create + EditAll
   • IngestionPipeline: Deploy + Trigger
     or something else?

2. For IngestionPipeline, is Trigger scoped to the resource working in
   1.12? Docs for 1.13 say Trigger is not registered on that resource
   descriptor and has to be granted under All Resources — which is much
   broader than we want. Is that still the case?

3. Test Library being admin-only is documented behaviour. Is that a
   deliberate design decision, or is it expected to become policy-driven like
   other resources? There is a TestDefinition resource in the policy editor,
   which suggests it is meant to be controllable.

4. Is there any supported way to let non-admins author new custom SQL
   definitions, even behind an approval step? Otherwise every SQL change needs
   an admin, which is the blocker for us.

Workaround we use today

An admin pre-creates and enables the custom SQL definitions in Test Library;
regular users then only instantiate test cases from them. This works, but
schema/SQL changes still queue up for an admin.

Related

• testDefinitions API: entityType query param is case-sensitive, frontend sends mixed case → 0 results for non-admin users #29542 — empty test type dropdown for non-admins (1.12.6)
• Fixes 29542: make the testDefinitions entityType filter case-insensitive on both the REST and MCP doors #31141 — fix, merged to main only
• Non-admin PUT of a new test case returns 404 since ANY authorization evaluates every request #36581 / Fixes 36581: Authorize a non-admin PUT of a new test case #36590 — non-admin PUT of a new test case

[Medamineelkhattabi]

I went through the 1.12.3-release code for this, and a few of the assumptions don't hold on that version, which changes the answer a bit.

Why the dropdown is empty

#29542 is probably not it. On 1.12.3 the form already sends entityType=COLUMN / TABLE: the enum member is called Column, but its value is "COLUMN". Two other things in that request matter (TestCaseFormV1.tsx#L655-L677):

• Any error from GET /api/v1/dataQuality/testDefinitions is caught and the list is set to [], so a 403 looks exactly like "no test types".
• The list goes through EntityUtil.addDomainQueryParam (EntityUtil.java#L1054-L1071). If the user has DomainOnlyAccessRole and no domain assigned, it overwrites the entityType filter with testDefinition and the query returns 0 rows. Admins skip this check, which matches "works as admin".

So as that user, I'd look at what the request returns in the browser's network tab, and check whether the user or one of their teams has DomainOnlyAccessRole. Listing only needs ViewBasic on Test Definition, and every user already gets ViewAll on all resources from OrganizationPolicy-ViewAll-Rule, unless you changed the Organization policy.

1. Permissions

What the API checks on 1.12.3:

Action	Check
Create a test case	CreateTests on the table or Create on Test Case
Edit a test case	EditTests on the table or EditAll on Test Case
Create a test suite	EditTests on the table or Create on Test Suite
Create / edit a test definition	Create / EditAll on Test Definition
Create a pipeline	Create on Ingestion Pipeline
Deploy a pipeline	no check of its own; it ends in an update that needs EditAll on Ingestion Pipeline

The table's executable suite is created for you (as the ingestion bot) when the first test case is added, so the normal Add Test flow doesn't need Test Suite permissions at all. The UI only creates the pipeline if it sees ingestionPipeline.Create, and only deploys it with ingestionPipeline.EditAll.

So a minimal set would be:

• Table: ViewTests, CreateTests, EditTests
• Test Case: Create, EditAll (and Delete if you want)
• Test Definition: Create, EditAll for the people who write custom SQL definitions. All isn't needed.
• Ingestion Pipeline: Create, EditAll
• Test Suite: only if they build logical suites (Create, EditAll)

2. Trigger

On 1.12.3, Trigger isn't in the Ingestion Pipeline descriptor (only CreateIngestionPipelineAutomator and EditIngestionPipelineStatus are), but the trigger endpoint doesn't check permissions at all on that version either. A check was added in #28109 (the docs say it's enforced since 1.12.9), and Trigger is registered on the Ingestion Pipeline resource from 1.12.13-release. So on 1.12.9 to 1.12.12 the docs note is right and it has to go under All Resources; from 1.12.13 you can scope it to Ingestion Pipeline. That alone is a good reason to move up within 1.12.

3. Is Test Library admin-only?

Not in the 1.12.3 code, whatever the docs page says. The route opens for admins or anyone with view permission on Test Definition (AuthenticatedAppRouter.tsx#L599-L611). Inside, the Add button needs testDefinition.Create, edit and enable need EditAll, and delete needs Delete. System-provided definitions stay read-only. There's also a Playwright spec (TestDefinitionPermissions.spec.ts) that runs non-admin users with Test Definition-only policies, so it looks intended.

4. Letting non-admins author custom SQL

That follows from 3: give the DQ authors Create and EditAll on Test Definition and they can add custom SQL definitions themselves. I didn't find an approval step for definitions. If you need a gate, split the roles: a small group with Test Definition Create/EditAll, and everyone else with only the Test Case and Table permissions above, so they can use the definitions but not change the SQL.

[SMZiminRu]

You are right, DomainRole was the problem we didnt have any test cases

Thank you very much for your help!