 Okay dope folks, I think we're gonna get started. So welcome, welcome, welcome to the nodes of the realm managing content access. And I hope you all get a kick out of my background picture here of my night, my night in like kind of armor. So yeah, and feel free to ask questions along the way. We'll try to answer them either as we go or at the end kind of depending on how it flows. But yeah, feel free to ask questions anytime. So yeah, let's just hop in. So my name is Jordan Thompson. I am a technical lead web developer at a company called Digital Kidna. And I guess that should have updated that. We just kind of merged companies with a company called Northern. So there should also be like a Northern logo there too. I've been in Drupal for like four, four and a half years now. You can find me on Drupal.org at Nord 102. I make a lot of cool stuff. I like building custom stuff. I am a co-maintenor in a few projects on Drupal.org. So I've dabbled, I've dabbled with some things. And this node access stuff is a pretty interesting complex challenge that I've had to kind of learn and not overcome per se, but more kind of like wrangle to figure out what I'm doing. So yeah. So what really are no realms and grants? And I know realm to most people kind of doesn't really mean too much. You know, you think like, as my title kind of suggests like Knights of the Realm, it's like, or like kind of medieval stuff, but that's not really the case in Drupal. So realms, what they are, their string, it's almost like an arbitrary string that represents grouped access, whether that be so that's like view, update or delete. But typically I try to recommend that they're fairly descriptive to like the purpose of the grouped access. So it could be a combination of view, update, delete. So like, you're giving them view access or you're giving them view update or view update, delete or any kind of combination like that. And we'll show in some examples as well to make it a little clear. This group access is a tract via a realm and a grant ID on a per node basis. So each node is kind of has their like that realm and that grant ID assigned to it. So saying, and you can have multiple realms and multiple grant like the grant realm ID kind of combination for the same note, you can have different ones, different kind of levels of access if you will. Like you could have a view one, you could have a view update, you could have a view update, delete. And they're all slightly different, but they're all targeting the same thing. And that's all stored in the database and the node access table. And by default, you'll notice on a site that's not really using any kind of custom node access, you'll see that there's an entry that just has a node ID of zero and a realm of all and even a grant ID of zero as well. So that's kind of just across the board allowing view access. So it's really not really granting anyone anything specific and it's just kind of a blanket across the board. But as we dive in to some code example, so to make kind of like define that realm, define that record in that node access table, we're actually using a hook called hook node access records. And what that does is on a per node basis, as you can kind of see as our parameter, there's our node, it's going to be kind of entering in those rows if we have any kind of realms that'll apply to that node. So in our situation, I've just kind of mocked up a pretend situation where we have all of our content types say have permissions that only the author can access their own content. So they can only edit and delete, but if you're not the author, you can't do any of that. And what if we wanted to open up that access on a per node basis? So not across the board, it's not saying that like an editor can edit all articles or basic pages. It's an editor can only say edit certain things that I want them to. So in our kind of pretend example, we have a field called field collaboration and it's a Boolean checkbox. So we're checking if that node has that field and whether or not that that value is true. So whether that's checked or not. So if we want to allow collaboration on our node. And you can kind of see here that we're defining our grant. So we're defining that realm, which we've just called collaborative. So you're trying to make it descriptive enough, but again, the word itself doesn't really matter too much as long as you kind of know what it's doing. We're assigning it a GAD of zero and we're doing, we're giving it a grant for view, update and delete. And this is where you can register kind of any kinds of realms you want. So it's really, and again, when you think realm, it's still realm and that GAD are kind of tied together. It's really that combination that you really need to have. And we'll kind of dive deep that, dive into deeper a little later. But that's how you define that. So what that kind of looks like in the database after it's actually shown or actually created is that you'll see, you know, we have our node IDs, got our GADs, our realms, and then it shows our permission. So I find that looking at this node access table kind of after the fact makes it a little easier to understand just because you're not explicitly defining that node ID when you're making that grant in that hook. It's applying to the node, but it's not super obvious on how it's working. So you can see that node 40 has a node access record of collaborative and node 41, node 42, et cetera. And then, you know, you can have different realms in here and different kind of thing like that. It's just a nice way to see it. So yeah, so realm, as I said before, like realm 40 could have multiple if it wanted to. Like if you needed that kind of level control, it could totally have multiple with different permissions and that kind of stuff or different access levels. But that's kind of how it looks. So when we're getting into grants, so first we made our realm, now we need to talk about grants. So grants what they are, they inform the node access system of what permissions the user has. So really if they're trying to perform an action like a view or an update or delete, there's a hook called hook node grants that runs and checks to see if that user should be granted access to the realm in that grant ID. And I'll show in a code example after this slide on kind of how we do that. And it's really like if they have access to the realm in the grant, then we're checking if that action that they're trying to do is even included in that realm. So say they're trying to do a delete action or like say they wanna have access to a delete action rather and they're in a realm that only allows them to view an update, then they're not gonna have access to that delete. Unless they're granted access to another realm, which then gives them that delete access. But it's on a per, again, it's on a per node basis and it's kind of triggering on a per like kind of attempt to do that action, if that makes sense. So really it's like the realms are kind of registering the rules and then the grants were kind of like security checks. So I kind of, the way I like to analogize it is kind of picture like you have a building and you have security cards, right? So though, you know, certain rooms have certain access levels and you have to have a certain like, you know, badge or security card to be able to enter those rooms, right? So that level of access is predetermined that certain people with certain types of cards, you know, have access to these areas. And then on a per door, you're checking, do I have access to this room? Do I have access to this room? And then, you know, maybe I can only look through the window, but I can't go in the door, which is kind of like your view versus like maybe an update delete. So hope that analogy kind of stuck a little bit. I thought it was kind of a neat analogy there. So what the code actually looks like for a grant. So that's a hook node grants, as I said before. And that's, as you can kind of see, now it's on a per account level. So it's checking, you know, when I go to do something on that node, check my account, see if I have some condition that allows me to get that grant. So in our example, we have defined or collaborative roles as editor, publisher, and administrator. And then we have a condition there that's, you know, checking if that user, that account on their get roles, if one of those, if they have at least one of those roles, which is what that array intersect is doing right there. For those who don't know, array intersect will kind of, it'll return array of anything that matches between those two arrays there. So as long as there's at least something coming over from that array intersect, then it'll grant true. And you can see we're granting them access to the collaborative realm on the zero GID. So there could be, you know, a collaborative realm with a different ID, a GID, and maybe that's a whole different set of permissions or a different realm. And that different realm has different permissions. So we're specifically giving editors, publishers, and administrators on a per node basis access to view, edit, and delete in our case. So we kind of see what that looks like on the database just to confirm again that, you know, I just kind of added in another set of realms there. So they're only having that grant view update and delete access from node 40 to 50. But that confidential realm, that kind of secret room that like super, you know, high security room or in that building in our analogy, they're not gonna have access to. They're only getting access to the realms and the nodes that are part of those realms that we're deciding on. So maybe there's another rule or say maybe only admins have access to that confidential area, for example. So you can get pretty creative and kind of very granular on what you're kind of assigning people, if that makes sense. So we've talked about realms, we've talked about grants, but how does, how do those realms actually get added, those rows actually get added to that database table? So something called rebuilding node access permissions. Use that technical, there we go. So when you add or update a realm in your hook node access records, you're gonna have to rebuild the node permissions because that hook doesn't actually run just like casually, doesn't just run like once an hour or any kind of set schedule. It does run when a node is created, but any of the node access rows that are previously existing and then say you update your realm permissions or you add a new one, you'll have to rebuild so that it'll pick up any of those new changes. So, and how that process of rebuilding actually works is that it truncates the entire node access table and then reruns that hook node access records for every single node in a batch process. So it's really going through and saying like, is there any access node access for this node? Log goes in, so maybe it only applies to one or two or three, et cetera, et cetera. And that trigger to rebuild those permissions is actually, it actually exists on the admin reports status page. So you'll kind of see a little screenshot here of the node access permissions area. It'll actually tell you how many permissions are in use. So my screenshot is from a site that has quite a bit. That's actually less than a number than we actually have. I think we have close to at least over 300,000, which is pretty crazy. And if you click that rebuild permissions link, it'll run that batch process and go through it. Now, just a note, and I'll kind of bring this up a little later in the gotchas section, it does take quite a long time to run that batch, depending on how many nodes on your site. Cause it is still going through each node regardless if it'll actually get a node access record later. It still needs to check everything, right? Cause there could be a chance where, you know, it didn't have an access record before and now it does or maybe you're removing it. So it really needs to know, you know, could kind of hone down that access. So alternative ways of rebuilding because that might take a really long time. And maybe you have a situation where you're only having node access say maybe for a specific content type or maybe a set of content types. And it's not the whole site. In my use case, it was for the majority of the content types. Node rebuilding did take a really long time. But these are some other ways that you can kind of do that. So again, I have a good solution, but not the best one is saving individual nodes manually. So when you do that resave, it'll check if there's any new or updated node access and then resave that. Now the better is if you can, you know, save sets of nodes with the content overview page, but the really the best solution, so like the best alternative is saving via these bulk operations on the content overview page. Because then you can do a filter maybe by specific content type or content types and you can kind of just save them all real quick. For example, you could save them by, you know, unpromoting them from front, for example, assuming that doesn't mess up with your promotion options. You can do stuff like that and it's just kind of an easy way to trigger that save. So I found that really helpful just from a time perspective, depending on, if you know, say you only changed a realm or a node access record that was only specific to a certain content type, even though you're doing node access for lots of them, maybe you just need to update that one content type and it'll take you, you know, 10 minutes as opposed to like a couple hours to resave everything. So that's just something to note. And something to note as well is because, and I will mention this later too, but I wanna bring it up just because it's a, it's a pretty big thing. If you don't let that node rebuild finish all the way, like some, if some reason it stops halfway, then only half of your nodes are gonna have that node access. So then you're gonna have users that can access things that they really shouldn't be accessing. So that's really, if you're ever rebuilding an access, especially on a really large site with a lot of nodes, that's definitely a time where you wanna kind of put in a maintenance mode, make sure it finishes all the way. Then once you're happy with it, let people back in. Cause even people using the site while you're rebuilding permissions, they're gonna be able to access things until that node then gets that, that access row. So it can be a bit tricky, but try not to do it too often. But once it's kind of set, it's set forever. And then those are the rules, the access rules, if you will. So now we're getting into alternative access control. So then that node access is good, but what if I wanna do other things? Like I wanna, you know, control access to like custom entities or anything like that. So there are hooks that do something similar. They're not really quite to the level of a node access grant or realm or record, anything like that. But it's still works for access control. So there's a hook entity access, which is technically also the hook entity type access. And allows you, allows to control access to non nodes. And I probably should have put their nodes as well because technically you can do it with nodes because it is an entity type, but you can do custom entities, you can do media, you can do files and anything like that. So you have to think too, the use case and kind of how this came up is that if you're limiting access or restricting access or granting access, I guess, to a node, you should also be kind of in turn managing that access with the media that the node is referencing and the files that are on the node. Because if someone can't access the node, but they can access the files that are being uploaded that node, that's not really restricted. They're still kind of getting around and kind of sneaking in it and kind of maybe those files are a little more confidential than the actual node data itself, right? So that node access grant is just on the node level. So anything that it's referencing or anything like that really needs to be kind of locked out. And another use case as well for some alternative controls actually denying access to nodes because that grant system only grants. It does not take away access. It's only kind of adding in that access. So we had a use case, for example, where it made sense to deny access to nodes where we had content being referenced on a form. So someone was filling out a form and we had to, we were auto-filling like a reference field but we didn't want to give that user the ability to view, edit, update that particular node but it needed to be referenced for them to save what they were doing. So we actually, it's kind of a weird like we were granting them access but then denying other access in a hook so that they could still reference it when they needed to but they couldn't actually view or do anything to that node. So I know that's a pretty specific example but you can really do a lot with these kinds of hooks and a code example for that is, so for custom entities, you can use that hook entity access and also show an example of the hook entity type access again, which is really the same hook. It really depends on how granular you want your hooks to be like you could have a hook per entity type or you could have just one big hook that does everything that really depends on your use case. The way I've broken down this for example is by entity type. So there's a switch for entity type and then there's a switch case for the operation. So as you can see, you have your entity, your operation and the account, all for any kind of context you need. So in say a view or an updated delete, you can tweak those to really be like an allow or forbidden or based on some kind of condition which could be coming from the entity which could be coming from the account. So maybe this user needs a specific role or specific set of roles or permission to do certain things or maybe the entity needs to have something checked on it or anything like that for that user to get that kind of access but it's a different type of access, right? This is on entity, it's not necessarily on nodes. And again, something to note as well is that we have as you can kind of see at the bottom there there's an access result neutral. So really what it's doing is if it can't if it doesn't actually fall into any of these categories so say we actually have proper conditions in our view, update and delete and it doesn't actually get to one of those return statements then it's just really kind of falling back to the default like permissions like in Drupal. So maybe they might actually have access to it say via a permission but we're actually denying them access because of some other condition before we get to that neutral. So that's totally a use case as well. So again, this is pretty bare bones but you can get pretty complicated. It really depends on your content and it really depends on how you're locking that down. So in our case for locking down media and files say that belong to a node that we're granting access to, you could say first we check if they should have access to that node and if they do have access to the node that the media is being referenced from then also grant them access to the media. So that's why it's really good that we have that entity so we can either find what's referencing it or find what maybe it's referencing something and kind of do it like that. So there's definitely some possibilities there on figuring out different ways to kind of make your content work but again it's really specific to how your content is structured and how you're either locking down or granting that kind of access to your users. So again, we have just like an entity type example so in this example I put in node so this is where you could still do some node stuff but really the granting is all happening through that hook grant node access records and the hook node grants. Whereas this might be something different and maybe we're denying some of that access here so there's definitely use cases for both. So I hope that makes sense. It's really hard to show a very specific example just as I said because like your content might be structured differently but you really have that granularity to pick on a per content type basis on a per operation basis if they can do certain things and also make a note too that it's important that you have that account there because you can check the role someone has if they're anonymous or not because maybe anonymous can view certain things but they can't or they can view all like published content but you're actually gonna take that view access away for specific content types for example like they can't even view articles for some reason and maybe that's what you want you can totally do stuff like that so there's just not endless possibilities but you definitely have a lot at your disposal and I think that that kind of makes that's why that makes this kind of difficult just because it's kind of hard to really hone down what you're gonna be using to kind of lock that down and yeah so hope that makes sense and just another way to do alternative access control is kind of leveraging entity references for note access so I kind of mentioned that a little bit with that media reference but we had an example where a user was actually referencing a note on their user records so what we were doing is we were actually specifying the note ID for the grant ID instead of say a user ID or zero and then we were then granting that user access to that realm with that note ID so like the realm was kind of like a generic realm of like maybe their role or something and then granting them using that note ID reference so that because the user has that reference it's like whatever you have a reference to you can access if that makes sense so it's just kind of another way to do it so before we were kind of doing it just based on in my example just based on like role for example but you can get pretty specific and it's actually kind of funny because this is the main use cases of what we use we didn't actually go as simple as just by role it was a little more complex on kind of sharing or referencing a note to gain access to that note so it's quite interesting so getting into the gotchas and I've mentioned a few along the way but there are definitely some I probably missed a couple when writing these but I think on like the whole of a concept of note access it's really hard to wrap your head around I think like the learning curve on figuring out like even just the words that I'm using like grants and realms and how the hooks work and when to rebuild and when to not rebuild and kind of like linking all those things together really takes some time to kind of figure out and I think it definitely makes it easier to learn if you start kind of with simple rules like in my example where you're starting with just like a role-based kind of realm access record and then you're granting maybe a specific user based on that so I think start off small and kind of work your way up to get complicated my use case we got really complicated and it was definitely hard to kind of figure out but once you kind of figure out how all those pieces work then you'll kind of get there but I definitely say it is difficult to kind of figure out and I hope everyone's kind of following along even though as I said the words are kind of difficult but hopefully if I've done my job right then you'll kind of have a better understanding at the end of this so that's the whole as I said before realms and grants do not deny they're only for granting access so just kind of remember that because it's a grant doesn't mean you're taking away anything you're just giving people you're kind of elevating their access as opposed to bringing you down so something else that to note is that no grants can conflict without site permissions are set up so typical configuration which I'd recommend is that you actually would deny users by default with permission so give them as minimal permissions as possible and then give them these node grants to kind of bump them up as opposed to granting them full access and trying to take away I always find that trying to add things is easier than trying to figure out and make sure that you're taking away all the access that they really shouldn't have because you might miss something and now they have access to an area of the site or a set of nodes that they really shouldn't have access to so really building those that access as opposed to kind of managing it in a weird like take down some but still leave some it's just kind of a weird system I find something noted as well is that node access checks will apply for all kind of access sorry, node access will apply for all access checks so when you're running like a view query or a database query like that those access checks are gonna be checked so it's whether or not they have view access right? So those are all gonna happen but those entity hooks that we were just looking at they're not gonna be fired in that kind of view so you'll have to just make a note that like some of that will have to maybe be controlled elsewhere or just kind of looked at I didn't run into too many troubles in my use cases just cause we didn't really use a ton of views per se it was more so either they were accessing the node and then the content like say like a media was already just on the node or they're accessing that media from a link directly so but again that's maybe just a flag that something you might run into I think I noted that before too that you always have to rebuild node access permissions when adding or updating realms in hook node access records but you do not have to do it when adding or updating grants in the grant system even that is kind of hard to figure out sometimes from at the beginning and it's because that the node grants is triggered when a user attempts to perform an action and not in general so it's like when they go to do something when they go to view something that's when it's like do you have access to it? Kind of similar back to my analogy the moment someone takes their key card and puts it on that pad, do they have access? is that's when it's checked it's not kind of any time so if we change those grants say today they don't have access to that door but we tweak the node grants and tomorrow they scan again they have access to that door we never had to do a rebuild there because the underlying access records are still the same we're just changing if they're being granted to them or not if that makes sense so that's I think the hardest thing is understanding like the node access record is really setting that underlying permission and that access level and the grants is just determining who has access to that who has access to the access if you will not to confuse even more and another thing is always make sure that that node rebuilds finished I think I mentioned that before but I did run into a situation where I was running it it was taking a really long time I left my computer I came back and it only half finished and it wasn't a good situation because then people started getting access to pages that they weren't supposed to be and this wasn't a good time so I definitely recommend like a maintenance window and making sure that those are all perfectly rebuilt and then you're good to go so yeah and I think this is a good we have some time to talk about questions and answers so this is good for questions and comments so I will go to the chat and just see what we got for questions or not okay so there is a question do you know if there's a way of invoking the needed VBO perms via rebuild via Dresch so do you mean like just like resaving everything but like an address command instead and it's a good question I think you probably could I think it would still be pretty timely though I feel like I don't know like I feel like views bulk operations pretty performant in that way I guess just because it's kind of doing I don't know it's pretty quick that I found but yeah I know that the batch and like timeout issues is pretty like not like not optimal for sure and that's why like you know if you need to do it if you need to rebuild everything I would rebuild everything but if you don't then try to do like a subset like if you're only adding in or updating something very specifically for a specific content type only update those only resave those because the other ones are just gonna be cleared out of that database table and then re-added so you're almost like wasting time by doing another like a full rebuild I kind of hope that answers your question I feel like you could probably do something similar with the Dresch command I specifically haven't I just kind of leaned on views bulk operations so another question can you use grants rounds to permit access to file attached to a node that is the node itself is public but the files attached to are not yeah so that's actually one of the use cases we had as well is that I guess in our case we had restrictions on the nodes and then we had to make the files also a similar restriction but yeah you could totally you wouldn't actually use grants and realms to permit access to the file because again files aren't the node the files are an entity so if I go back in my presentation real quick you'd be using it's like hook entity any type access hook and that any type would be a file and then based on some kind of permission or role or anything like that you could restrict those kind of files to certain people if that makes sense so that node grant like the grants and the realms are only for nodes specifically anything else you're going into like hook any type access territory which has a little bit less control per se but you're still it's still the basic idea right you have the view you have the update you have the delete so same principle it's just I'd say it's maybe a little less robust in a way just because the node one gets saved like those get saved in a table those access and it definitely applies to more places than the website as I said like in view queries and that kind of stuff so but it definitely could work for files I definitely had to do that for files for sure because yeah we had some that had media but also straight up files and we had to make sure that they had specific access to that good question another question wouldn't saving all the nodes reset update time potentially messing up sorting logic good question if you do it in such a way so if you were to manually do it for each one that wouldn't that would apply but I think if you do it via views bulk operations and someone can correct me if I'm wrong but if you do it via like a views bulk operation I don't believe the updated time gets switched there's a way to do it such in such a way that like the update date doesn't actually get updated it's like kind of like a weird workaround where you're resaving it but it's not actually doing anything so the update date doesn't actually change if that makes sense so I'll have to trust me on that one so I'm pretty sure that that's how it works but someone can correct me if I'm wrong yeah it's like a weird hacky way to do it but I think if you were to go into the node manually and do it I think that would update the time I'd have to try it out again to specifically answer that question but I would try it on maybe just a subset and just see if that works but I'm fairly certain like 85% certain that I won't mess up the date question when would you use this in code and when would you use permissions in admin so really the use case on on using those node grants versus kind of relying on that permission system is I guess you could you could technically like you know make specific permissions for accessing like specific content types but I feel like at that point it's a lot of work with custom permissions because you're really getting view access to say publish content or anything like that so you really it's not as granular as you might want it to be and it does really allow you a lot of control on who can do those kind of updates like the view update delete on a per content type basis or on a per well not per content type I guess per node but like those very specific things like you can get really granular like in my example like if this box is checked or this field is checked on a node then it's going to grant like a whole section of users to do it and that's not something that's necessarily easy to do or kind of easy to kind of customize in like the default permission system like it's really not built for that level of granularity and I know permissions are pretty granular as a whole but I think you can just get a little more custom with this approach and just the ways that you're limiting that kind of access or granting that kind of access rather so if that answers your question like I think that the use case for this is specific per site like if you have a site that's just like all public everyone can see anything if it's published then like you never have to worry about node access but once we're starting to talk like certain logged in users should only have access to certain things when they're logged in and it's too granular for like certain nodes that they should have access to so like user one should have access to node 40 and 45 but nothing in between like that's when you're getting like really into the weeds for the granularity and that's when this really plays a good part in it so I hope that answers your question another question is have you ever tried using grants realms to make more granular layup or permissions like letting user edit the layout of a node but not the node itself as a good question on my specific project that I implemented this node access on we actually weren't really leveraging too much of layout builder but I have used a lot of layout builder so I don't think that's a good question actually because I think edit access because there's a specific permission for layout builder but I know that that permission from what I remember is kind of across the board it's either you have layup builder permissions or you don't it's not like on a per content type basis which I kind of think should be a thing like you can only do that but I guess I guess that is kind of the split there because if you can edit that piece of content generally you can do the layout but if you only wanted to do the layout I think what you're saying yeah I think that's hard it's a hard question just because it's like half of the editing I think you'd have to like kind of lock down maybe more of like the route for the edit perhaps so so like they couldn't edit like they couldn't access the edit page but they could access the layout page but I don't know if that would necessarily be using the grant system per se I mean you could still be doing that but maybe you're kind of slicing that that update in half in like a hook entity type access instead I'd have to try it out but I think that would be the case like you see you can still have those no grants and then in that operation update then maybe you try to figure out whether or not they should be allowed to edit versus layout or both if that makes sense I hope that answers your question I haven't specifically tried it myself but that would definitely be an interesting one cause I know that that definitely comes up another question are there any contrived modules you find particularly in this realm kind of open intended I know there is one I think there is one called like no grants or something like that I didn't use it I think it's I think it maybe provides I don't actually know what it provides I think it provides maybe like a user interface maybe something like that but I didn't use any contrived modules specifically for this I kind of just relied on code examples online and the Drupal docs which I've linked to all the hook docs by the way on all the slides that have hooks on them so I recommend to check them out but yeah it's hard cause like I feel like the majority of websites don't even have to worry about node access it's either it's a public website and everyone can view everything or or it's like maybe like an internet and you have to be logged in anyways to see stuff you know what I mean like this is where it gets into that weird territory where like you're splitting that kind of access on a per node for either logged in or maybe logged out users like it's kind of like you know it's definitely the unusual case so yeah I hope that kind of answers question I guess it doesn't really answer your question cause there's no contrived modules that I use but I would just recommend like playing around with those hooks and that's really all you need I think I have like a specifically like in my use case I had a module that just had any kind of user access related things so any kind of access hooks or anything like that was all just in one module so that it was like nicely combined so all these hook any type access even if it was like a block access or anything it's just kind of locked down in this one specific module so yeah hope that answers your question another question did you consider using the content access contrived module rather than you can custom code so it's a good question I'm going to just quickly google that cause that yeah I think that's one of the contrived modules that is out there but whether or not I want whether or not we used it so I will say that it's not currently covered under security not to say that it's not necessarily a good module but it does look like there's quite a bit of people using it I think I definitely considered it yeah it looks like it's using like kind of conditions like more rule based maybe so I guess it depends like I feel like you could maybe use that that module if it works for your case I know that my specific example was like very custom so it really required a lot of custom code so I don't think that content access module would be able to get to like the level that I needed but I definitely wouldn't be opposed to saying that that's not a good module to use for this again it really depends on your use case like my examples were my project had a lot of specific things that people had to meet to then get access so it wasn't as simple as like role or something like that it got really granular at certain parts so I think maybe that content access one that module is maybe better suited for a little less complex situations but still something that it supports I imagine that there's like a set of rules that you can use to kind of denote that but I think at some point you might have to get custom again depends on your use case but I hope that answers your question as well and we did hit 245 or 545 depending on your time zone so feel free to reach out if you want to talk to me about this presentation or have any questions again I will relink the slides in case you want to check that out thanks for coming out thanks for talking a cool topic