Nice work Feng. We were waiting for this from our end.
Looking forward to contributing for the upcoming feature for DAG group
access control.
Martin
>
>
>
>
Awesome work Feng. Well done.
On 17/07/2018, 13:27, "James Meickle" wrote:
Really excited for this one - we have a lot of internal access controls and
this will help us implement them properly. It's going to be great being
able to give everyone access to see the overall state of D
Really excited for this one - we have a lot of internal access controls and
this will help us implement them properly. It's going to be great being
able to give everyone access to see the overall state of DAG progress
without seeing its parameters or logs!
On Tue, Jul 17, 2018 at 12:48 AM, Ruiqin
Congratulations! Extraordinary work! Thank you very much! This has been a
highly desired feature for us for quite a while.
Cheers,
Kevin Yang
Tao Feng 于2018年7月16日 周一下午9:30写道：
> Hi,
>
> Just want to give an update that Airflow DAG level access just checked in
> today(https://github.com/apache/inc
Hi,
Just want to give an update that Airflow DAG level access just checked in
today(https://github.com/apache/incubator-airflow/pull/3197). Thanks a lot
for Max and Joy's review which helps me improving the pr. I create the
following three tickets as a follow up:
https://issues.apache.org/jira/
Hi Max, Joy and Everyone,
Based on the discussion, I put up a work in progress pr (
https://github.com/apache/incubator-airflow/pull/3197/) with a doc(
https://docs.google.com/document/d/1qs26lE9kAuCY0Qa0ga-
80EQ7d7m4s-590lhjtMBjmxw/edit#) for DAG level access. I would like to get
some early feedb
Hi everyone,
Thanks a lot for all the great discussions. To summarize in brief, here are
the few approaches we discussed so far:
1. One permission per DAG. The user has homogenous rights on the dag.
The concerns:
- not flexible to certain use cases(e.g the user has view only access on
+1!
I was originally tempted to re-use existing perms and views for dag-level
access control since dag-level perm/view is a subset of view-level
perm/view, but your proposal of defining new dag-level perms/views
independent from view-level perms/views is interesting. This actually makes
a lot of s
I'd suggest something else that avoids having to add a 3rd column. I think
we can fit our use case into the existing structure nicely.
My idea is to mimic what FAB does with its own Models.
When you create a Model and ModelView in FAB (say DagRun for example), it
creates a new view_menu (DagRun)
Hi all,
I also agree that having view-only access to some dags while write access
to other dags is useful, so I prefer option 2. Although option 2 is more
difficult to manage, it is cleaner and more consistent with the current
security model. (On the other hand, even though option 1 may be may be
(Creating a new thread)
Hi Max,
I was just wondering about this. There are definite use cases for people
having only view access to some DAGs, mostly for monitoring. I want to know
what the upstream DAGs are doing, but maybe I don't need clear/run access.
I feel like the granular operation permi
11 matches
Mail list logo
