Issue 1:
Apache Airflow version:

1.10.11

Kubernetes version (if you are using kubernetes) (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-16T00:04:31Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"}

Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-13T06:39:58Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: Azure Kubernetes Service

OS (e.g. from /etc/os-release): Debian GNU/Linux 10 (buster)

Kernel (e.g. uname -a): Linux airflow-web-65cb7d9cb8-qzcbv 4.15.0-1089-azure #99~16.04.1-Ubuntu SMP Fri Jun 5 15:30:32 UTC 2020 x86_64 GNU/Linux

Install tools: Helm chart "stable/airflow"

Others:

What happened:

After upgrading from 1.10.10 to 1.10.11 (and also with new installs of 1.10.11) there are some permission warnings in the webserver logs:

[2020-08-14 22:19:30,022] {manager.py:545} WARNING - Refused to delete permission view, assoc with role exists XComModelView.can_add Admin
[2020-08-14 22:19:30,038] {manager.py:545} WARNING - Refused to delete permission view, assoc with role exists XComModelView.can_edit Admin

It seems to be directly related to #9614 that @kaxil introduced for 1.10.11 which removes the can_add and can_edit permissions from XComModelView, but Airflow can not delete the permissions from that view because relations to those permissions still exist on the "Admin" and "Op" roles.

In more technical terms, the two permissions can't be deleted from ab_permission_view table because each have relations to both the Admin's and Op's role_ids in the ab_permission_view_role table.

What you expected to happen:

No warnings with Airflow 1.10.11

How to reproduce it:

Install 1.10.11

Either:

View the logs of the webserver

Run any airflow CLI command, such as airflow list_users and view the outputted log messages

After a few lines of the log you will see the warnings

Anything else we need to know:

If those 4 role permissions are removed from the ab_permission_view_role table the warnings should stop. I think a migration needs to be added, or some logic that cleans up these role permissions is failing to do its job.

Issue 2:
Description

I don't believe backfilling (of data) is not well handled in Airflow at the moment.

I believe the current backfill CLI command should have a UI component on the webserver - not the least as many deployments of Airflow doesn't expose a CLI interface to the users - only to admins.

I would also like it to handle the following cases:

Backfill a DAG for execution dates where it has already run.

This essentially is the same as clearing all DAG-runs between those dates. The current UI forces me to manually clear the runs, I can toggle "Future" or "Past", but nothing like a "Range Between".

Backfill a TASK for execution dates where it has already run

This is essentially the same as above, except instead of clearing the whole DAG, it would clear a task, and potentially all downstreams from that task. A common use case here is when a new task is added to an existing DAG and you want to re-trigger it for historical dates. Currently the new task will have no execution, but the DAG it was created into will have successful runs for those dates.

The above, including execution dates where it has not run

In both the above examples, specifying a start_date before pre-existing DAG runs should insert those DAG runs and execute them. It should also insert any missing dag-runs between the dates where it has already run, in case those have gone missing.

I'd be happy to provide some of the functionality in a PR, but I am not a skilled frontend developer.

Use case/motivation

Altering a DAG or task is a common use-case, for instance if an improvement to some business logic has been made - or a bug has been found and fixed. Restoring the status of those produced datasets easily is then important.

Here's both the case where you want to re-run DAG executions, and insert new DAG executions for historical dates that may have been cleaned up to save space in the DB.

Related issues

I am certain this has been raised and discussed in the past. It is the number one feature I miss from working with Luigi - where I could easily re-trigger historical task-runs.

Are you willing to submit a PR?

Yes I am willing to submit a PR!

Code of Conduct

I agree to follow this project's Code of Conduct