-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add back decorator has_access
#34786
Conversation
@vincbeck @ashb Should we also update the public interface document to include |
I would definitely say yes. I would do it in a separate PR though, mainly because I dont really know how to explain besides saying: "Many plugins are using this decorator historically" :D One of you want to take a chance at it? |
I don't have a strong opinion on this, but as I understood in the original discussion, this decorator should not be in the public interface, but just maintain it because it was used since Airflow 1 for plugins, and we kept it in Airflow 2. |
That's true too ... I guess we are in some kind of grey area here. But what you said makes sense to me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR adding this back. I assume just one pydoc issue. Otherwise code looks promising.
Regarding the public API my opinion is that the code properly adds a deprecation warning and points to the new API - which we then should declare as public. Agree that the previous API was a gray area but for the proposed new entry points at least we should make it better.
What I did not fully get with the new API methods are, these are specific to the UI areas. If I add a MyPlugin
then I would need to add a has_access_my_plugin()
decorator, the ones existing are specific to the existing UI.
So besides public API would be good to add some hints into the plugin authoring docs - If you don't want to raise a PR I could if you help me in understanding.
Co-authored-by: Jens Scheffler <95105677+jens-scheffler-bosch@users.noreply.github.com>
Yes it can be an option. If you implement
Yes, happy to work together on this one. Please feel free to create a PR and tag me on it and I'll be able to review it. Or you can ping me on Slack if you want |
Promise to contribute this after merging this PR... |
@utkarsharma2, @ashb, @hussein-awala Any comments? |
@vincbeck Thanks for adding it back :) changes look good to me. |
See comment thread.
has_access
decorator seems to be used by many plugins. Hence, in order to avoid breaking them. Adding back this function.@utkarsharma2, @ashb, @jens-scheffler-bosch
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an 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 a newsfragment file, named
{pr_number}.significant.rst
or{issue_number}.significant.rst
, in newsfragments.