bug: Removing custom Superset assets

[bmtcril]

In testing #107 , I created a custom superset row level policy and jinja filter. Upon turning off my test plugin and removing it, the jinja filter we removed from the python file but the security policy remained. This causes all queries on the filtered tables to fail.

I had to manually remove the row level security policy from the admin ui. If we can't automate removing these, which I suspect would be a huge effort, we should document the steps needed to deal with this issue.

[Ian2012]

Maybe we want it to be optional, like a drop command or cleanup superset and cleanup clickhouse, so we don't have to manually drop the tables or the data from clickhouse, nor manually delete the assets for superset.

This way, in already running installations with modifications we can sync dashboard changes without breaking anything.

[Ian2012]

The superset constraints are complex enough and this work impact it's not really valuable at this stage of the project.

We will consider this issue stale

[Ian2012]

@bmtcril We can start using the tagging system with tags for all Aspects created assets, allowing us to remove all non-Aspects assets. However, only charts, dashboards, and saved queries can be tagged.

[bmtcril]

What do you think about tagging assets with their language (and a special tag for the un-localized "original" assets), and the Aspects version number they were created with? Then we could clean up things that a) were orphaned from earlier versions or b) untagged, meaning they were created manually with different command line switches. We could also let operators tag assets with something like "keep" so they never get cleaned up.

[Ian2012]

I had in mind the tag for the language. The idea for the Aspects version number should help clean up known orphaned assets.