ethan-l-geotab commented on PR #32969:
URL: https://github.com/apache/superset/pull/32969#issuecomment-2773134199
Thanks for the feedback.
So currently this PR is just in a state where it’s UI labels. For now, it’s
just to kick off the thought process as to accountability and visibility of
“charts in draft”. Right now it's just a sign of “hey, im done with this chart,
I think it’s in a ready state for people to look at!”. The accountability is to
double down on the certification, and to work in tandem with dashboards
publication status. More in the answered questions
I was really just testing the waters I guess to gauge interest without
fully committing to writing a SIP (It’s a little more overwhelming to me to
propose a plan rather than just sorta do it and see the interest).
To answer a few of those questions:
- The migration currently sets it all to draft. I think it might actually be
better to set it to publish to keep the current state where “everything is
considered published”
- The ones who can publish a chart currently I believe should be the ones
that can currently make changes to the chart with the “canOverwrite”.
- It is the intention that in the future, only published charts can end up
on published dashboards. No dashboard should be published with unpublished
charts. This is so that we have a baseline of "production ready” standards for
all “production ready” dashboards where all the charts on there are “ready for
production”. However, if we don't want cascading, thats fine too.
- Currently a draft/published status does not have access on RBAC. It’s just
the UI stuff. However, if someone has a better suggestion on how to handle the
privacy that would make sense in a Superset-y way, that’ll be cool.
Questions I can’t answer yet:
- What happens to a published chart when it’s unpublished and on a dashboard?
I’m not too sure how to handle this:
1. Unpublish the dashboard but pop a warning for the user that they will
unpublish the dashboards (should they even have permissions to unpublish
dashboards with their chart on them?)
2. Show a warning perhaps that now there will be published dashboard with
unpublished charts?
3. Block unpublishing. If changes need to be made to the chart, then perhaps
a versioning system could be developed where a “new published” chart could take
the place of the old one, but that’s a bit of a can of worms…
4. This isnt a problem if there is no cascading anyways. Big fan of keeping
things simple....
With all that in mind and the current state of the PR, i was hoping that
since it's feature flag, i could dodge the SIP, but i think for sure that the
full vision of whats in mind, i think a SIP would be unavoidable. This was only
intended to be the foundational work on which these features, permissions and
controls would be added over time.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For additional commands, e-mail: notifications-h...@superset.apache.org
