Allow all default roles to view Profile page + allow editing profile/resetting password if it's DB-ModelView

[XD-DENG]

This is a change discussed long time back in #3889 (comment)

Currently, ONLY Admin role is allowed to view "Profile" page, and edit profile info or reset password there. All other roles will get "Access Denied" if they click this Your Profile button.

The ideal situation should be:

• all (default) roles should be able to view their profile page.
• all (default) roles should be able to edit their profile (change first/last names), only if the webserver is DB-based.
• all (default) roles should be able to reset their password, only if the webserver is DB-based.
  (For example, if the webserver is using LDAP or OAuth, users should NOT be allowed to edit their profile or reset password.)

Essentially, the 7 permission-resource pairs are added for all default roles:

• can_this_form_post on UserInfoEditView
• can_this_form_get on UserInfoEditView
• can_userinfo on UserDBModelView
• userinfoedit on UserDBModelView
• can_this_form_post on ResetMyPasswordView
• can_this_form_get on ResetMyPasswordView
• resetmypassword on UserDBModelView

In addition, can_userinfo are added for all other possible User ModelViews (UserOIDModelView, UserLDAPModelView, UserOAuthModelView, and UserRemoteUserModelView. Reference)

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[XD-DENG]

Hi @ashb @kaxil @turbaszek , this PR is to implement what has been discussed long time back in #3889 (comment) . @ashb has done very thorough analysis in that discussion, and this PR is simply following what has been discussed there.

Understand now the focus in on 2.0.0rc1. Take your time if you have no bandwidth on this, and I can ping again only later.

[github-actions]

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*.

[ashb]

I thought I made this change aaages go, clearly not :D

[github-actions]

The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest master at your convenience, or amend the last commit of the PR, and push it with --force-with-lease.

[XD-DENG]

I thought I made this change aaages go, clearly not :D

Yes, something from long time ago 😄 I happened to revisit this. Credit to you for the very detailed analysis you have done.

[kaxil]

cc @jhtimmins

[jhtimmins]

@XD-DENG @kaxil For the new resource-based permissions, we're actively trying to create resources that reflect the underlying data, rather than a specific view. In terms of actions, we're trying to stick to Read, Edit, Create, and Delete. This will allow permissions in the UI to be used in the API as well if we choose to include all UI functionality in the API at some point.

We can either revert this PR or create another PR to get these permissions in line with the existing approach.

[ashb]

@jhtimmins These are views/perms from FAB-managed views, so I'm not sure we can do much about them (at least not easily?)

[XD-DENG]

As @ashb mentioned, all these are the "built-in" stuff provided by FAB, and actually they have almost zero linkage with Airflow itself.

So personally I don't think it's making sense to "re-create" anything on top of them.

[XD-DENG]

Updating milestone to 2.0rc2 since I notice this has been cherry-picked into the latest 2.0.0rc2