bugraoz93 commented on PR #26467: URL: https://github.com/apache/airflow/pull/26467#issuecomment-1256926568
Hello @ashb, thanks for your comment. I wrote a bit-long comment, sorry about that. I tried to think loudly to explain my thoughts on the issue and implementation. Yes, the management is possible over the `access_control` attribute. Using access_control like in the example is the same thing as adding a DAG resource to a Role (like `can read on DAG:dag1`). Rather than adding from UI for all DAGs that the team owns (`Role:team1`), we are adding this information from the DAG and leaving the management to DAG maintainers. You are right, the use case can be managed over the `access_control` attribute. The feature is already provided. Of course, there are some pros and cons to using this method. I think It is a matter of how we want to manage the permissions. The use case and implementation are just extending the `access_control` over the `owner` attribute. From the administrator side, using the `access_control` attribute moves the role management to the DAG level. Once the DAG is updated and reloaded to Dagbag, it will always override what is set on UI for the role. This could be a hard thing for the administrators because it needs to manage the roles from DAG rather than UI. From the DAG maintainer perspective, the maintainer can give delete permission to any role with the `access_control` attribute. This can cause the deletion of important DAGs by mistake. If we use the UI to set the permissions, the situation can be prevented. The use case can reduce the visibility of the role management on DAG. It may provide elasticity to Airflow administrators and extend the Multi-Tenancy feature. I think it could be similar to the `filter_by_owner` configuration on the previous versions such as `1.10`. Since the Owner attributes can be also used for filtering the DAGs, I think this attribute could be more widely used than the access_control attribute. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
