 Hey, here's a quick update on the policy-based access in core Both issues where I add the API and I implement the API in core are reviewed and tested by the community Test code green. They all work. I just wanted to give you a quick View of what becomes possible when this is added into core So as you may or may not know this whole system is Based on the flexible permissions module which is being converted into core and the group module already relies on flexible permissions So it already has access to all of these these goodies basically With this system basically the thing that happens is that You calculate someone's permissions when we are trying to check for someone's permissions and they haven't been calculated before So it becomes this cache entry where all access policies on a given website Can add or remove permissions to the whole set and then that set gets cached with the right cache contexts So that everyone gets that set of calculated permissions provided they have the same global context variables So we don't ever have to calculate that more than we need to Once you get these permissions then access checks simply work like they always did But the upside is that you can have your access policies that you currently have in core such as Your permissions that you get from your roles and whether you are user one or not And you can start adding policies to that or start removing from them So you could disable user one if you wanted to now in group This is a bit more complex in group. We don't merely hand out permissions in this, you know global context of We're in a Drupal website in group We actually have smaller sections of your site We have these groups where you can put a piece of content in and you expect only people who are a member of that group to be able to see that piece of content This is why this API has a notion of a scope So in Drupal you wouldn't care about that in Drupal You would simply hand out permissions and it would automatically put it in the Drupal scope But if you want to hand out permissions in different scope such as group or domain or what have you then you can and you Need to specify a scope identifier Simply put group has three of these Whether you are a part of a group and a role is assigned to you individually Whether you are part of a group and you happen to have a certain global role Whether you are not part of a group and you happen to have a certain global role So group has three of these scopes Which is a bit more complex than your general use case But when I try to determine access to a grouped entity both on the query and in actual access checks Then I need to check all of these scopes and I actually for query access convert them into conditions So all of that happens in a group module and you may be asking okay, that's a lot of information a short amount of time Why do I need to know this? Well, you'll see how powerful the access policy API is when it's properly implemented by the modules So to give you an idea I am currently on the first domain of my local dev instance and I can only see the first group If I go to the second domain and I go to groups. I can only see the second group Now if I were to go to admin contents, I can only see the page in my second group If I do that on my first domain I Can only see the page in my first group This is because of a new module that I created group sites, which basically is one big access policy It doesn't do much else. It doesn't do any query alters. It doesn't do any access hooks It just alters your permissions using the access policy API. This is really important to remember It also comes with this toggle that if you set this admin mode on them Basically the group sites module doesn't do anything so that you can properly configure your website So if I toggle this on you can see how fast that was and now I can see both pages even though This is in group one and this is in group two But I'm only on the domain for group one if I go to my groups listing now you can actually see that I have three groups Which is really cool. If I turn that off again Then now I can only see my first group again and this is based purely on an access policy So there is no query rewriting nothing going on Now, what does that look like if I actually go to The admin content view on the third domain where I'm logged in as the admin so I can do everything Well currently the admin mode is off and on the third domain There are no groups because I didn't tie any to a domain So what would happen is I wouldn't be able to see any contents no content available and you can see that there is this query rewrite which basically applies group Permissions in a way that it won't always return false because you know you have no access now if I turn this admin mode off You'll see that instantly I can see these pages again, and now there's a lot more being added to the query Because now I have different permissions and because my permissions gets turned into query conditions the query conditions alter But again, I didn't write any code for that all I did was implement a single access policy If I log out on the second websites So log out and log back in as an admin So now I have full control I go to views again Then it will become a lot more clear what's happening So if I go to admin content here Then you can see both of them are returned because admin mode is on and you have a lot of stuff added to the query But if I turn my admin mode off now, we should only show notes that are within group 2 And if we look at the query rewrite right now, it becomes more simple There's one left either joined less or fewer and we actually have this condition now that basically checks your group I didn't need to be to again all of this happens With just an access policy So the module that does this is really tiny what it looks like right now is if we go to groups We go to site settings You have a context provider which I wrote one basically giving you a group that's tied to a domain When we couldn't find a group tied to the domain we deny all access. That's what you saw on the third domain You could also set that to do nothing then nothing happens And the access policy when we did find a group is that the single group remains active now Obviously, that's a bit more complex to show but I can give you a quick peek So we have this access policy right here In the alter permissions methods, we're gonna do nothing if the admin mode is on We only support those three scopes that are defined by group We add to write cash tax. We're gonna try and get the context value So that would be the group coming from the domain if we find a domain We add that as a cashable dependency so that caching still works when you toggle the admin mode on or off Or if you switch domain We try to get that context value and validate that it's a group And then we call either the access policy when there is a group So when there is a site or when there is no site when there is no sites, we have one of these deny all Basically just calls remove items so that all of your calculated permissions are just tossed out Do nothing does nothing as you would recall or as you would expect sorry and then finally The one that happens with the single site. That's complex. I'm not gonna go into detail because this basically It basically it still removes everything But it does a lot of Massaging to the one single group that remains active and it adds that one back in that's what's happening here That's what you're seeing So yeah, that is one example of what you can do with the access policy API and as you may have noticed It's blazingly fast So it instantly works. So I'm here because it's cashed. I turn admin mode off Boom. It just just works. It's awesome