Skip to content

Conversation

@jhtimmins
Copy link
Contributor

Deactivate the trigger, refresh, and delete DAG buttons on the DAG details pages if the current user doesn't have the necessary permissions to perform those actions. This was added to the DAGs list page in 2.0.1, and is now being added to the detail page as well (not including it before was an oversight).

@boring-cyborg boring-cyborg bot added area:UI Related to UI/UX. For Frontend Developers. area:webserver Webserver related Issues labels Feb 9, 2021
@jhtimmins
Copy link
Contributor Author

@kaxil @ashb @ryanahamilton

Copy link
Contributor

@ryanahamilton ryanahamilton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nittiest of nitpicks

@jhtimmins
Copy link
Contributor Author

Thanks @ryanahamilton

Copy link
Contributor

@ryanahamilton ryanahamilton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you had previously asked me if there was anywhere else this needed to be updated… Unfortunately my previous response ("no") was wrong. The Task Instance views also inherit the same dag.html, so you're going to need to add _add_user_permissions_to_dag(dag) to each of the following methods in views.py too:

  • task
  • rendered_templates
  • rendered_k8s
  • log
  • xcom

image

@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from 3674ca6 to 4999b4b Compare February 9, 2021 22:38
@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from 4999b4b to 98fdb68 Compare February 22, 2021 23:05
@jhtimmins jhtimmins requested a review from ashb as a code owner February 22, 2021 23:05
Copy link
Member

@ashb ashb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it's worth using the before_render_template flask signal to automatically inject this in all templates that have a dag object in the context? https://flask.palletsprojects.com/en/1.1.x/api/?highlight=before_render_template#flask.signals.signals_available

Copy link
Contributor

@ryanahamilton ryanahamilton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My changes were addressed. Will leave it to you to determine if the additional refactoring suggested by Ash should be included in this PR.

@github-actions
Copy link

github-actions bot commented Mar 1, 2021

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest master or amend the last commit of the PR, and push it with --force-with-lease.

@github-actions github-actions bot added the okay to merge It's ok to merge this PR as it does not require more tests label Mar 1, 2021
@ryanahamilton ryanahamilton removed the okay to merge It's ok to merge this PR as it does not require more tests label Mar 1, 2021
@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch 2 times, most recently from a8ec497 to 362f638 Compare March 2, 2021 03:00
@jhtimmins
Copy link
Contributor Author

@ashb updated to use the signal

@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch 2 times, most recently from 412b4c7 to a9fc88d Compare March 4, 2021 00:39
@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from a9fc88d to 6f736d1 Compare March 4, 2021 01:00
@github-actions
Copy link

github-actions bot commented Mar 4, 2021

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

github-actions bot commented Mar 4, 2021

The Workflow run is cancelling this PR. Building image for the PR has been cancelled

@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from 6ef8afc to eb44807 Compare March 4, 2021 01:33
@github-actions github-actions bot added the okay to merge It's ok to merge this PR as it does not require more tests label Mar 5, 2021
@github-actions
Copy link

github-actions bot commented Mar 5, 2021

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest master or amend the last commit of the PR, and push it with --force-with-lease.

@kaxil
Copy link
Member

kaxil commented Mar 8, 2021

Tests are failing @jhtimmins

@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from eb44807 to 66d895c Compare March 9, 2021 20:47
@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from 66d895c to c8520d6 Compare March 24, 2021 03:33
@jhtimmins jhtimmins force-pushed the deactivate-dag-controls-on-detail-view branch from c8520d6 to a11cf76 Compare March 24, 2021 22:10
@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@kaxil kaxil added this to the Airflow 2.1 milestone Apr 3, 2021
@kaxil kaxil merged commit 3a38134 into apache:master Apr 3, 2021
@kaxil kaxil deleted the deactivate-dag-controls-on-detail-view branch April 3, 2021 00:10
@kaxil kaxil modified the milestones: Airflow 2.1, Airflow 2.0.3 Apr 3, 2021
potiuk added a commit to potiuk/airflow that referenced this pull request Apr 3, 2021
This PR fixes a problem introduced by apache#14144

This is a very weird and unforeseen issue. The change introduced a
new import from flask `before_render_template` and this caused
flask to require `blinker` dependency, even if it was not
specified before as 'required' by flask. We have not seen it
before, because changes to this part of the code do not trigger
K8S tests, however subsequent PRs started to fail because
the setup.py did not have `blinker` as dependency.

However in CI image `blinker` was installed because it is
needed by sentry. So the problem was only detectable in the
production image.

This is an ultimate proof that our test harness is really good in
catchig this kind of errors.

The root cause for it is described in
https://stackoverflow.com/questions/38491075/flask-testing-signals-not-supported-error

Flask support for signals is optional and it does not blinker as
dependency, but importing some parts of flask triggers the need
for signals.
potiuk added a commit that referenced this pull request Apr 3, 2021
This PR fixes a problem introduced by #14144

This is a very weird and unforeseen issue. The change introduced a
new import from flask `before_render_template` and this caused
flask to require `blinker` dependency, even if it was not
specified before as 'required' by flask. We have not seen it
before, because changes to this part of the code do not trigger
K8S tests, however subsequent PRs started to fail because
the setup.py did not have `blinker` as dependency.

However in CI image `blinker` was installed because it is
needed by sentry. So the problem was only detectable in the
production image.

This is an ultimate proof that our test harness is really good in
catchig this kind of errors.

The root cause for it is described in
https://stackoverflow.com/questions/38491075/flask-testing-signals-not-supported-error

Flask support for signals is optional and it does not blinker as
dependency, but importing some parts of flask triggers the need
for signals.
potiuk added a commit that referenced this pull request Apr 5, 2021
This PR fixes a problem introduced by #14144

This is a very weird and unforeseen issue. The change introduced a
new import from flask `before_render_template` and this caused
flask to require `blinker` dependency, even if it was not
specified before as 'required' by flask. We have not seen it
before, because changes to this part of the code do not trigger
K8S tests, however subsequent PRs started to fail because
the setup.py did not have `blinker` as dependency.

However in CI image `blinker` was installed because it is
needed by sentry. So the problem was only detectable in the
production image.

This is an ultimate proof that our test harness is really good in
catchig this kind of errors.

The root cause for it is described in
https://stackoverflow.com/questions/38491075/flask-testing-signals-not-supported-error

Flask support for signals is optional and it does not blinker as
dependency, but importing some parts of flask triggers the need
for signals.

(cherry picked from commit 437850b)
ashb pushed a commit that referenced this pull request Apr 15, 2021
This PR fixes a problem introduced by #14144

This is a very weird and unforeseen issue. The change introduced a
new import from flask `before_render_template` and this caused
flask to require `blinker` dependency, even if it was not
specified before as 'required' by flask. We have not seen it
before, because changes to this part of the code do not trigger
K8S tests, however subsequent PRs started to fail because
the setup.py did not have `blinker` as dependency.

However in CI image `blinker` was installed because it is
needed by sentry. So the problem was only detectable in the
production image.

This is an ultimate proof that our test harness is really good in
catchig this kind of errors.

The root cause for it is described in
https://stackoverflow.com/questions/38491075/flask-testing-signals-not-supported-error

Flask support for signals is optional and it does not blinker as
dependency, but importing some parts of flask triggers the need
for signals.

(cherry picked from commit 437850b)
@potiuk potiuk removed this from the Airflow 2.0.3 milestone May 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:UI Related to UI/UX. For Frontend Developers. area:webserver Webserver related Issues okay to merge It's ok to merge this PR as it does not require more tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants