mistercrunch commented on a change in pull request #5099: Dashboard level
access control
URL:
https://github.com/apache/incubator-superset/pull/5099#discussion_r194570629
##########
File path:
superset/migrations/versions/76a4d742cf04_dashboard_role_many_to_many.py
##########
@@ -0,0 +1,29 @@
+"""dashboard role many to many
+
+Revision ID: b21a4c518cab
+Revises: e866bd2d4976
+Create Date: 2018-03-08 16:30:36.924096
+
+"""
+
+# revision identifiers, used by Alembic.
+revision = '76a4d742cf04'
+down_revision = '5ccf602336a0'
+
+from alembic import op
+import sqlalchemy as sa
+
+
+def upgrade():
+ op.create_table('dashboard_role',
Review comment:
Hey so the model so far has been to *not* create these many-to-many tables,
and instead creating perms for each object (table, database, schema). This has
pros/cons, one of the pros being to have the security model limited to FAB's
RBAC tables. Meaning roles are only made out of users and perms. Then perms act
as imperfect FKs to the object table. Cons is the fact that the join is
imperfect as we want the perm object to be human readable, but contains the id.
I think I like the approach here, made possible by the fact that we now have
`SupersetSecurityManager` and can specify `rolemodelview`. I can see how we'd
move to do pattern for `Databases`, `DruidDatasource`, `SqlaTable` at some
point. I'm not sure what others may think about this approach.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For additional commands, e-mail: notifications-h...@superset.apache.org
