jhtimmins commented on pull request #11362: URL: https://github.com/apache/airflow/pull/11362#issuecomment-715055912
@ashb Updated the docs and Log resource names. Regarding the updated Task vs Task Instance resource names. It occurred to me when executing a task, the API handles this by creating a Task Instance object. Since there isn't an explicit "Task.execute" permission, I don't think it makes sense to get rid of the Task Instance permission altogether. It theoretically makes sense to use `Task Instances.can_create` to control execution access. Possible ways to handle this. 1. Use both `Task` and `Task Instances`. Don't worry about having multiple endpoints with both `Task.can_read` and `Task Instances.can_read` permission. 2. Use `Task.can_read` for almost everything. Only use `Task Instance.can_create` or `Task Instance.can_delete` for endpoints that explicitly run or delete task instances. If an endpoint currently has `Task.can_read` and `Task Instances.can_read`, consolidate this into `Task.can_read`. Consolidate reads, leave create/edit/delete in place. 3. Consolidate everything. Swap out all occurrences of `Task Instances.can_X` for `Task.can_X`. I'm fine with any of the three that you think make sense, but I think #1 makes the most sense, followed by #2. Thoughts? ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
