ashb edited a comment on issue #8112:
URL: https://github.com/apache/airflow/issues/8112#issuecomment-657798116
Right now we have `can {add,list,edit,delete} on PoolModelView`:
Is there ever a valid use case where you want want a user to have permission
only to edit (for example) Pools over the API but not the WWW UI (or via WWW UI
but not the API?)
I can't think of any, and I would very strongly like us to not make the
security screens any harder to use than they are, and having two permissions
for the "same" end effect (i.e. editing Pools) would do that.
I think this would work to make the existing name clearer:
```python
class PoolModelView(AirflowModelView):
class_permission_name = "Pool"
```
(See
https://github.com/dpgaspar/Flask-AppBuilder/blob/85567d5a15a48aa2ca1950515af379fe347b912a/docs/security.rst#permission-customization)
That would then look at "can_edit on Pool" which makes sense as a permission
name for both WWW and API endpoints.
(There's a bit of migration work here to update old mappings to new, but
that seems achievable.)
What do you think of this approach? Basically I am proposing changing the
permissions from one view=one permission to the view is mapped to one of CRUD
(plus a few special case) on the model it operates on.
So I think most of the *ModelView permissions and the API permissions (which
map to almost the same thing) should be tied to the same permission
> I don't think that editing permission for Dag, DR, TI is required in this
case
If we first say "read on Dag, DR", then I can see arguments either way. But
at the very least the equivalent of `has_dag_access()` would be needed on
DR/TI, even if we don't need a direct grant of "can_read on DagRun" or similar.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
