[
https://issues.apache.org/jira/browse/AIRFLOW-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17112152#comment-17112152
]
[email protected] commented on AIRFLOW-85:
-------------------------------------------
This is a delivery failure notification message indicating that
an email you addressed to email address :
-- [email protected]
could not be delivered. The problem appears to be :
-- Recipient email address is possibly incorrect
Additional information follows :
-- 5.2.1 The email account that you tried to reach is disabled. Learn more at
https://support.google.com/mail/?p=DisabledUser l204si1906404ybb.461 - gsmtp
This condition occurred after 1 attempt(s) to deliver over
a period of 0 hour(s).
If you sent the email to multiple recipients, you will receive one
of these messages for each one which failed delivery, otherwise
they have been sent.
> Create DAGs UI
> --------------
>
> Key: AIRFLOW-85
> URL: https://issues.apache.org/jira/browse/AIRFLOW-85
> Project: Apache Airflow
> Issue Type: Bug
> Components: security, ui
> Reporter: Chris Riccomini
> Assignee: Joy Gao
> Priority: Major
> Fix For: 1.10.0
>
>
> Airflow currently provides only an {{/admin}} UI interface for the webapp.
> This UI provides three distinct roles:
> * Admin
> * Data profiler
> * None
> In addition, Airflow currently provides the ability to log in, either via a
> secure proxy front-end, or via LDAP/Kerberos, within the webapp.
> We run Airflow with LDAP authentication enabled. This helps us control access
> to the UI. However, there is insufficient granularity within the UI. We would
> like to be able to grant users the ability to:
> # View their DAGs, but no one else's.
> # Control their DAGs, but no one else's.
> This is not possible right now. You can take away the ability to access the
> connections and data profiling tabs, but users can still see all DAGs, as
> well as control the state of the DB by clearing any DAG status, etc.
>
> (From Airflow-1443)
> The authentication capabilities in the [RBAC design
> proposal|https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+RBAC+proposal]
> introduces a significant amount of work that is otherwise already built-in
> in existing frameworks.
> Per [community
> discussion|https://www.mail-archive.com/[email protected]/msg02946.html],
> Flask-AppBuilder (FAB) is the best fit for Airflow as a foundation to
> implementing RBAC. This will support integration with different
> authentication backends out-of-the-box, and generate permissions for views
> and ORM models that will simplify view-level and dag-level access control.
> This implies modifying the current flask views, and deprecating the current
> Flask-Admin in favor of FAB's crud.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
