Hello, I have updated the approach to make it more compatible with FAB. The most important change is the departure from changing the authorization model. The complexity of managing multiple permissions will be implemented by adding a new screen that will facilitate the management of permissions for the API and the Web simultaneously.
Thank you very much for paying attention to this problem. I hope you enjoy this approach. Best regards, Kamil On Thu, Mar 19, 2020 at 1:31 PM Ash Berlin-Taylor <[email protected]> wrote: > > -1 (binding) for the moment, sorry. This is mostly because of the proposed > permissions solution. > > I am happy with the spec-first approach, and feel we can get there on > the exact API methods, what IDs we expose or don't etc, but this > permissions is a deal breaker for me as it stands. > > From your last response I am still not sure 100% what you are proposing, > and it feels like we are fighting against FAB rather than working with > it. For example you say: > > > all we have to do is replace steps 4 and retrieve information from the > > code, not the database. > > Do the permissions management screens in FAB still work -- i.e. can > someone choose to give a user/role access to only a single API endpoint? > If so how do we achieve that without having to re-write the Security > screens from FAB. > > What is wrong with the FAB database approach that means we have to re-write or > customize it's behavoiur? > > Yes our current permissions approach isn't great, but that is just how > we've "chosen" to do it in Airflow, it's not a problem with the > underlying permissions model. For example a different way of doing it: > > https://github.com/apache/airflow/pull/7251/files#diff-948e87b4f8f644b3ad8c7950958df033R2719-R2722 > > This added a (AJAX-style) method to DagModelView, and reuses the > "can_list" permission to achive it - because the "action"/verb is about > listing, it doesn't ever make sense to deny autocompletion if you can > list. > > If I understand your proposal correctly, you are suggesting something > like "can_edit_variable on APIView"? Why not "can_edit on > Variable" (or VariableView), and then that one permission could apply to > web UI and API. (Without the "on X" part I think a lot fo FAB won't work > right.) > > So specific things I want to see addressed before I will +1 this. > > - How do we manage API permissions for custom roles? (i.e. do the > existing screens work, how usable are they?) > - What "ViewMenu" is the permission tied to? > - What do these look like the Security screens? > - How do we manage these API permissions on a per-DAG level? > - Are we unifying the API permissions and the front end-permissions? > > I feel we are close on this AIP! > > Ash > > On Thu Mar 19, 2020 at 10:55 AM, Jarek Potiuk wrote: > > +1 binding > > > > > > On Thu, Mar 19, 2020 at 10:32 AM Tomasz Urbaszek < > > [email protected]> wrote: > > > > > > > +1 binding > > > > > > On Thu, Mar 19, 2020 at 10:29 AM Kamil Bregu=C5=82a <kamil.bregula@polide= > > a.com> > > > wrote: > > > > > > > Hello all, > > > > > > > > This email calls for a vote on the design proposed in AIP-32, found her= > > e > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+RES= > > T+API > > > > > > > > > > > https://lists.apache.org/thread.html/r2a0d0fb3d4610432fa52148d7d9e59c7632= > > dd8f2fa61a580430b814c%40%3Cdev.airflow.apache.org%3E > > > > > > > > A few notes: > > > > > > > > - The proposed in AIP is to use an the "Specs first" approach. > > > > First, we make the change in the openapi.yaml file, and then > > > > we change the code. > > > > - This AIP allows for high granulation. Many people can work on > > > > smaller independent tasks. Already the application from Outreachy > > > > internships asked me how they can work on this AIP. > > > > - Details of the API structure may still change until the first version > > > > is released. > > > > > > > > This vote will last for 72 hours until 2020-03-22T10:30Z, and until at > > > > least 3 votes have been cast. > > > > > > > > > > > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?iso=3D20200322T1030= > > &p1=3D262 > > > > > > > > This is my +1 vote. > > > > > > > > Thanks, > > > > Kamil > > > > > > > > > > > > > -- > > > > > > Tomasz Urbaszek > > > Polidea <https://www.polidea.com/> | Software Engineer > > > > > > M: +48 505 628 493 <+48505628493> > > > E: [email protected] <[email protected]> > > > > > > Unique Tech > > > Check out our projects! <https://www.polidea.com/our-work> > > > > > > > > > > > > > --=20 > > > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > >
