Using AD groups for object ownership

[dpc]

Databricks has a general issue with object ownership in that only the creator can delete them.

So, if I create a catalog, table, view, schema etc. I am the only person who can delete it.

No good if it's a general table or view and some other developer wants to delete it.

Or if you create it within a notebook and want to test that the notebook works e.g. a notebook that creates or replaces a view that you change. SO, what do you do if another dev needs to work on it

Also, what happens if the individual leaves after historically creating a number of tables that the own.

Some time ago I asked the question and was told that databricks was looking at AD group ownership (or some other form of grouped ownership) i.e. the groups owns the object, so if you are in that group you have the same ownership rights rights.

Is that still in progress as I cannot find anything further.

Either I am missing a point or the whole ownership area is still not very good.

Thanks

[Raman_Unifeye]

@dpc - you can alter the table ownership to a group using ALTER command which means all the members in that group (Sayd dev) will be able to delete it as needed.

In case of a leaver, those tables can still be deleted or ownership transfer can be done by Admin.

[dpc]

Thanks.

I'll give this a go.

Didn't think it was an option previously

[KrisJohannesen]

I believe the MANAGE permission on the object(s) would give you this ability as well. Not that using groups in in any way a bad idea - just for your information 

[emma_s]

Hi, to add some further context to this, the Manage permission, as Kris says, is the way of achieving this, and giving it to a group would be the recommended way. At the moment, though, the manage permission also allows the users to share the table with other members too. Within the next year, there will be further permissions available that also give drop-only permissions to users.

[dbxdev]

I had the problem with another client at a much larger scale.This is what we did .

At the end of each pipeline that we ran in the development environment we had an AlterOwnership task.When a user runs a pipeline with his/her credentials all the objects he or she creates will get altered to the user group permission of the schema ( the user group that have access to create objects in the schema) dynamically . So we didn't have to hard code the user group . It would pick it from the defined permissions on the schema . This task would run irrespective of the case if any other task in the pipeline succeeded or not . 

For other objects created outside of the pipelines we asked users to have a pipeline with their id as run as and the tech lead with full permission over the pipeline . This pipeline would run the alter ownership task to fix the ownership in case the user left .