 Okay, it's one o'clock. We're going to go ahead and get started. This session is on the Drupal 8 group module. What can the group module do for me? So before we get started, we wanted to do a quick little survey. We know this is a virtual event, so I wanted to just kind of get an idea of where everyone's watching from. So I've seen a couple of DC Baltimore, which is surprising. Oh, Costa Rica, that's awesome. Quebec, Florida, nice Oregon, so from all over. I think that's one positive thing that comes out of having a virtual event as you can really join from anywhere. Illinois, a lot of California, probably missing it, having it in person, of course. The next question we'd like to know is who here has used the group module in Drupal 8? Does anyone have experience at all? It looks like a variety of some, a few, some not at all, some in D7. Tried installing it and got lost. Well, hopefully we can help you out here. Okay, a couple of people want to. Okay, our next question is actually who has used organic groups. It looks like I'm already seeing some people who have used organic groups. So the group module is kind of an alternative to organic groups. So it looks like people have used organic groups. I think I even used organic groups in Drupal 6, but obviously I'm more of a fan of the group module at this point. All right, great. Thank you. Thank you, everyone, for your feedback. So as we go along here, feel free to post your questions into chat. If you could post, if it's a question that we want to address at the end, if you could kind of preface it with a Q dash in front of it so we can easily pull those out. We're going to basically wait until the end to answer all the questions, but feel free to answer or ask them as we go. So just to start off, my name is Deborah Fuzetto. I'm a technical architect at Forum One. I've been working with Drupal since 2006 and have been building websites since the mid 90s. I live and work on my 60 foot aluminum sailboat called Heavy Metal with my husband and two teenage boys. My passion is Drupal and sailing. My name is Mark Mayan. I've been making websites for somewhere around 15 years, which scares me every time I say it. I've been working with Drupal for quite a while and I've been working with digital agencies a good portion of my career as well. I really have been getting into machine learning in the past year or so. I have a strong interest there and I also am pretty interested and have some domain knowledge around DevOps stuff as well. Since they're kind enough to employ us, I just wanted to give a quick shout out to Forum One. Thank you Forum One for employing me. They provide some great benefits. They've been really good about COVID. Everybody's remote at the moment. I'm a technical architect here. They're often hiring, so check the website if you're interested. Things change daily, weekly, so I'm not totally up to speed on what we're looking for, but definitely check it out. Another thing that I really enjoy about Forum One is that they don't kind of accept every single client. They often accept clients that have an ethos or a mission, which really makes me feel good about the kind of impact that they bring. And speaking of which, here's some of the clients that we're going to be talking about today in some use cases as well as some just broader broad strokes clients that we work with on the whole. Feel free to ask me any questions independent of this if you're interested about any more information about Forum One, but I'm going to toss it back to Deborah to give some broader broad strokes information about group itself. So the first thing I'd like to talk about is what a group is in general. So according to the dictionary, a group is defined as a number of people or things that are located close together, kind of like these awesome little finger people, which is kind of they are the little logo for the group module. So people in groups interact and engage and identify with each other. The group members are share common interests, and they come together to work on common tasks for agreed purposes and outcomes. So don't do for a group what a group can do for itself. This is a quote from Emily Axelad, and this quote is originally intended to address meeting effectiveness. But in my opinion, the quote is saying that you should take advantage of what a group can do on its own. Groups can be more effective than individuals. And because groups offer more perspectives and ideas, groups can have more creativity together. So how does this relate to the group module? Well, the group module, it creates collections of your content and users on your site and can grant access control on these collections. This can allow you to create communities for people with similar interests or needs and can control how and when people have access to content. There's many use cases for the group module, and we're going to talk about some specific use cases in a bit. The group project page also points out some typical examples for the group module as well. So a group in Drupal is an entity making them fully fieldable and extendable and exportable. Groups work well with views and rules and other Drupal modules. And the group Drupal 8 module also uses the plug-in system, so it allows you to easily extend its functionality. So the group module itself comes with several sub-modules out of the box. And I think one of the most notable ones is group node. The group node module is one that you'll definitely want to check out. It provides functionality around content types and allows you to add nodes to a group and share access to group members. Our use cases will show how this sub module is in use. So the sub-group modules also allows you to have a group belong to another group, which is an interesting idea. I've never actually used it, but I can definitely see some use cases for that. The group member profiles provides the ability to show memberships of a group in a curated way by creating multiple fieldable member profiles, which can be attached to a member. So there's also a lot of contributed modules that can be added to expand what the group module can do. One of them being the group media module, which can associate media elements with a group. Another really useful module is the entity group field module, which is useful because it provides a computed field that allows you to know what the group associations are. So a lot of times when you're editing a node out of the box, you can't really see what group this node is actually associated with. And this module allows you to present that. So you always can know what groups are associated with an entity that you're editing. Another module group outsider in, which we'll talk about again later, it addresses how the outsider and the member roles play together. So the permissions model of an outsider doesn't quite work quite right without this module. With advanced outsider permissions, you can apply permissions to a Drupal role, but once that user becomes a member of the role, those permissions are overwritten by the permissions of the member and that person then loses those permissions. With a group outsider in module, this basically takes care of that. So there are two modules that are associated with group menus, and I'm going to let Mark talk about them because he has most experience with and has actually helped create one of them. So the group menu module is very traditional in the way menus are handled in Drupal 8. And so far as that in the normal Drupal 8 ecosystem, when you create a menu, it gets exported as configuration. The group menu module does the same thing. I worked with a client and got the ability to create a different approach, which was with the group content menu module. With the group content menu module, you're able to create menu types, much like you are with group and also node. And those group types allow you to do all the things with menus that you can do with content types, so you can field them, etc. Also, each instantiation of a menu instead of being individual config is actually content itself. And I think that that plays a little more well with the group module because group entities, which we'll talk a little bit more about, are content. And so there's nothing for the menus to get related to that make them kind of belong to a group. And so I think that group content menu is an approach that I like a little better, but I'm biased because I got to participate in its creation. Next, I just wanted to give some overall architectural concepts of the group module. As I've kind of hinted at already, there are group types. They work similar to bundles. As bundles work with node, you can instantiate new group types like an organization or a department or an office, etc. And those group types are individually fieldable. And those group types also have the ability to associate permissions with them, which is the great things about it. Next, the group entity is a standalone entity. It implements the entity class. And so therefore, you get a lot of the nice things that come along with entity. One of the more interesting nuances of the group module is this group relationship entity, which is the connector between how group relates content to node and also relates to users, which is in the form of a membership. So when you become a member of a group, you kind of create one of these relationship entities, which ties together the user and the group. Each of these relationship entities are also fieldable. And so let's, for instance, say that you wanted to display a little moniker on a particular group of, you have been a member of this group since XYZ time. Well, you retrieve that timestamp from this relationship entity. Another kind of powerful thing about the group module is it's extensible and well implemented out of the box roles and permissioning system. Deborah started talking about this already, but an anonymous user is exactly as it is in Drupal, which is the anonymous role, anybody that's not authenticated. An outsider is somebody that is authenticated, but isn't a member of the group. The advanced outsider roles, which again, Deborah is going to get into a little more depth about, are basically instantiation of Drupal roles, but in the context of a group. And you can create your own custom roles, which I'm going to talk a little bit more about in a little bit here. The permissions documentation for a group is really good. I saw somebody already ask about if we'll make these slides available so you can click on this link that I have in here. I'll work on that and figure out how to get that done. The next thing I wanted to talk about is some challenges that you'll need to be aware of when you go to use the group module. Right now, it's a module that has 400-some-odd files, I believe, and so it's a pretty robust module. And so that means that whenever you go to upgrade the module, especially with a major version release or something like that, there's going to be some things that you're probably most likely going to need to address. Paying attention to patch notes and update notes are important to see if there's commands in need to run, et cetera, stuff like that. Alongside that, it's a very robust issue queue because people have really started embracing this module, and that means that people are finding more and more use cases. And so an example of this is the integration with the group module with media that started as a patch and got spun out into its own unique module. So we're going to talk about some more patches in a minute. The other things to note is that when you're like in the context of a node, there's not like an administrative way out of the box that shows you how that node relates to a group. And so there's definitely some user interface updates that need some help. Just my personal opinion. So next we're going to talk about some of those patches. One of the things that I've had to work a lot with on clients and their needs is the needs around editorial workflow. In the permissions grid, which you'll see some screenshots of in a little bit, there's not the same Drupal permission grid transition granular items in the permission grid. So like for instance, if I want to change something from draft to published, that's a transition. And that transition is listed in Drupal's permission matrix, but not in the group permission matrix by default. This patch is going to help with that. Same thing with the lightning scheduler. If you used AQUIA's lightning functionality, it provides all sorts of things. But one of the things it provides is the ability to schedule content to transition from one state to the next at a particular time. And those transitions also have their own separate permissions. And so I've got a patch for that. I don't have it in the GitHub repo that I shared some code samples with for this, but I can get it in there. And so I'll share it in there at the very least. There's also some token module patches that allow URLs to be a little bit more robust. In the case of using group menus in any consideration, there's no easy way and token to establish a path auto pattern that says XYZ group and then all of its supported content as an additional path. There's no way to figure out what the parent group is. So this patch helps with that. I've also attached a couple patches that help with the administrative experience. So next, I want to talk a little bit about some differences between DA group and organic groups. I saw that in our little survey there that people are very somewhat familiar with organic groups or many of you are. One thing that's nice about DA group is that it does instantiate its own entity, as I said a little bit ago. You don't have to relate this functionality with node or with taxonomy in order for it to work. I'll also caveat by saying I have not used the organic groups DA implementation. So if any of this has been solved, I apologize in advance. There's also innate operability with core and a lot of core concepts. It instantiates the entity class. And so you get a lot of the nice to haves there. It works well with views, even though there is some additional functionality that I have implemented, which I'll talk about to make it work a little bit better with views. But on the whole, clicking around in views, you see a lot of things that you're accustomed to in the group context. And from my reading of the contrib space of group module, I definitely appreciate that translations has been taken into account. I'll caveat that by saying I have not done a multilingual site with groups, but from my eyes have read the code that says they at least tried. So there is that. It's also written up first. So it's been very easy for me to extend it. And so I have definitely appreciated that, that it's kind of a ground up approach and with the eight and mind. And I'll also say that, you know, there's no, there's no like seemingly stable release organic groups yet in the D8 space, while D8 has felt stable and does have a stable release. So next Debra is going to talk about her use case. I'll pass it off to her. Great. Thank you, Mark. Great. Thank you, Mark. So I'm hearing an echo. Is everyone hearing that? Maybe that's better. Okay. Anyway, so it's common to want to have, so content ownership is basically the concept behind my use case, because it's common to want to have content owned and displayed by different groups. So an example of this use case could be for an organization who has a high level association and associated chapters. So the association provides like an overview of the content where the chapters are more specific to their locations. All content on the site is owned by a group. So basically in this use case, you don't have the ability even to really add, you know, content the regular Drupal way. So we actually wrote some custom code to alter the route that doesn't allow you. It basically will restrict you from adding content the regular Drupal way. In this case, we are also using the group module as perspective. So it's the chapter editors who belong to the group rather than the visitors of the site. And that belonging to that group gives you access to be able to add or edit content within that group and media. And it does not have access to anything else outside of that group. So the visitors of the site don't actually have to join the group to see the content. In this particular case, we use geolocation to geolocate the user based on their IP address to set a chapter based on their location. And the users can see chapter content from other chapters, but they are more led towards the chapter that is as nearest to them. So this use case had some very specific requirements. One of the requirements being that the association group, the kind of main level group had full ownership over the content, even the content that was owned by the chapters. So even though the association wouldn't be a member of that group, they needed to be able to have full access to the content, to be able to help the chapters create their content and edit their content and make any changes that were necessary. So the group content also had to have specific page elements. So like breadcrumbs and a custom footer for the group pages in addition to local menu, but they shared the main site menu. So I'm going to talk a little bit more about some of the challenges that I had around these specific page elements. So the groups also are not able to add existing content from other groups or media. That was another requirement that they had. And also, yeah, so they couldn't use content or media from other groups. So in anything that they added to their group was not available to other groups. So and again, the admin role, the association would be able to override any other groups that they are not a member of. And another requirement was that the chapter itself would have a landing page. So this would be like a kind of a group landing page. And I'm going to talk a little bit about how I did that. So the solutions to meet these requirements were not really very complex. I did have the need to have individual group types, one for the association and one for the chapter. So you pretty much need to have a different group type when you're considering different entities that are going to be available to a group. So the association, for example, has access to all content types where chapters only have access to some specific content types. I also implemented the group media module, which allowed me to associate the media with the groups and also configured outside permissions on chapter groups to allow association users with admin roles to have full access over the group content. So the group view is what I used as the landing page for the chapters. And because the groups themselves are entities, you can add as many fields as you want to the group. And that allowed me to have a very robust landing page for the group. So this screenshot here is how you would be configuring your group content. So this is for a specific group type. And you have basically all of your plugin information here. And your examples of plugins are like your different content types, your media types, could be your menu, it could be your users. And you can also write custom plugins to put here as well. And for each one of these, for each one of the types, you can either enable or disable based on the needs that you have for your group type. The next slide here is showing how fields are added to a group type. And you can see that this is similar to what you would do to a content type. So you have your managed fields area where you can add as many fields as you want. I basically used these fields to not only manipulate the landing page, but also to be able to enter content about what would show up in the footer. There's also external URLs that are used for like donation pages. Each one of the chapters have different external URLs for donation pages that can be defined in the group on a field that I can access within other components. And you also have your form display, just like you would with content types, where you can manage different widgets for each of the fields and also your managed display, which displays how the fields are displayed to the users. So permissions were a very important part of this use case. And there's basic permissions that were set for members and the anonymous user. And the advanced outsider permissions were used to grant access to the association over chapter groups and content. So the next slide here, you can see a screenshot of your basic permissions. You can see here you have your anonymous, your outsider and your member roles. These are your group roles. And you can assign what access they have. Are they able to join the group? Are they able to edit content? Can they view the content and other things through basic permissions? And then when you get into your advanced permissions, your advanced outsider permissions, this is where you're going to see your actual Drupal roles. And this is where you can grant access to a specific role that kind of overrides what access you would have as a regular outsider on your basic permissions. So moving on to the challenges for this use case, I would say probably the one thing that we struggled the most with were around permissions with media. So the media, the group media module works very well out of the box to allow media to stay within the groups. And chapters couldn't see media from other chapters. But when it got into your outsider role, there were issues with being able to, because your outsiders are not actually members, I don't think the group module, the media module takes into account that these outsiders have the ability to add media. And so they have the ability to add media, but then they can't go back and see the media that they've added. So we had to write a little bit of custom code around that in order to kind of override that. And I think that the group media module is maybe a little bit immature and has some work to go with working with all the other things that are going along with the group module. So the other thing was allowing access for the association for all chapter content. So we've talked about this a couple of times. So I used the advanced outsider permissions to grant access for different roles to be able to manage the content and the media within the group, even if they weren't a member of the group. But if they became a member of the group, they would lose all permissions and not be able to really do anything other than what a regular member would be able to do. So the group outsider in module basically comes to the rescue there and allows you to still maintain those permissions, even if whether it's intentional or unintentional that the user would join the group. So breadcrumbs and path aliases were also a bit of a challenge in my situation. So again, the path auto patterns that you define is really kind of a site wide. It doesn't really do it per group. And they're really not the same. They weren't the same for the association as they were for the chapters. So there was, we had custom aliases that were created when pages were created. And also we had to manipulate the breadcrumbs in order to display them at the correct level that we wanted to display them at. So in this particular use case, I did not use any of the group menu modules because the chapters themselves do not have access to manipulate the menu. And all of the chapter pages were inside of the main menu. So if you were to use your breadcrumbs based on your menus, it would show all of the hierarchy previous to the chapter level. And we really want to just start at we wanted to just start at the chapter level. So there was some manipulation that had to be done with the breadcrumbs in order to get what we really wanted. The other thing, and I had mentioned this before too, is that on the chapter pages, they wanted custom footers for the specific chapters. So, you know, on the site overall site, there was an association footer, but on pages that were chapter specific, they wanted to also have a footer that was very specific to the chapter. This was not really very easy to do out of the box, but what I ended up doing is taking the information that I needed for the chapter and adding fields to that group type. And then at the front end layer was able to determine if it was a page that was owned by a chapter, then I could pull out the values from those fields and build out the chapter that way. I also mentioned that I use the group view page as like the kind of landing page for chapters. So if you were, whether you were geolocated or you were just wanting to go to a specific chapter, you would have a landing page that would have information about what the chapter was about and what other content was in the chapter. It worked great except for the, you know, you couldn't really create a draft of it. So because it was configuration for the group itself, it wasn't really, you know, it wasn't really a, there was no really revisions available. So you couldn't like create a revision of it if you wanted to make changes to it. It was like, if you wanted to make a change to it, it just had to be made. It wasn't, so it's not really treated the same as like regular content. So I think all in all, the group module was a really great solution for this use case. And even though it required some custom code and additional module, it was a really easy solution to implement. So now let's hear about some of Mark's use cases. Thanks Deborah. So a lot of the challenges that I faced are, you know, similar but build upon things that Deborah covered. I'm going to try in my use cases to build on the things that she had described and only kind of described the things that were unique to my experiences. So one of the clients that I got to work with was a local municipality. And as you'd expect with the municipality, they have a police department, a fire department, a parks and rec, etc, etc. And so listening and tailoring, listening to them and tailoring to their needs was pretty interesting. The types of things that we needed to address was a relatively complicated workflow process. They also needed scheduling, which I talked a little bit about earlier. You know, for instance, every year, leaf collection occurs. And so going around and capturing leaves or snow removal or whatever, those are very cyclical things that they have to deal with every year. And so tailoring needs around those kinds of requirements was very important to them. This was a space where we did use the group content menu module. This is the client that actually funded its original contributed space. It allowed the ability to relate several pieces of content together so that, you know, for instance, your parks and rec department can put all their parks in a singular menu and make things a little bit more navigable. And then they wanted to use groups purely in an administrative capacity really, like there's no front end group entity view mode for this particular client. They just wanted to be able to segment different users into groups and allow them to administer content in a safe space where they can't break out of the rest of the system and edit pages that they're not supposed to. So as that follows on, that they had like 200 some odd contributors that are going to be working on content and they belonged to a couple dozen different groups. And so it was a pretty robust experience. They also had a need to be able to authenticate via SAML on ADFS. And while we didn't use any information at the point of authentication to power groups, I definitely see a lot of potential there where if they wanted to expose to me who, you know, what group they belong to, we could have done some interesting work around automatically creating groups and associating with them rather than content administrators having to do that. So I think that there's, you know, this gave me an insight into like some cool things that you could potentially do in the future. As I already talked about, the group menu solution is what helps some of the groups relate content together. And then they really wanted to focus more on the administration experience more than anything else. We used large chunks of their existing website to theme the front end. This was really a lot about tailoring the back end. So this is where they started where a lot of content administrators, well, the content administrators were at the municipality level. And basically all these content stakeholders would make email the content admin, their like forward content edit changes, which made them very sad over time. Because as you can imagine, that's pretty grindy. And where we arrived at was to push all of that kind of work down to the individual department level so that these content administrators could log in and manage their content effectively. This opened up the people at the municipality level to kind of focus on broader challenges, which made them happier. Some of the customizations that we did for this client as it relates to group was that I wrote a little views plugin. Like if you can imagine the default Drupal content listing interface, it lists all the content of all the content types. And they wanted a similar experience for group members. But rather than seeing all content, they only want to see content that pertains to them. And we needed to write a few different not rights, we needed to create a few different view displays that had the same sort of functionality. And so this plugin kind of takes into account the permissions that a user has, and only exposes content to them that they have actual access to be able to edit. I also had some UI enhancements around routing. There is a check box on the settings page for groups that allows you to like tell it to use the administrative theme. But it's actually not ubiquitous. There's still a few different places where it by default, it wants to drive you to the front end rendering of what a group looks like. And so for this client, since they're only really using it administratively, we overwrote some routes with a route subscriber to take care of those needs. If we have time at the end and people are interested, I can get into these GitHub links, but I can see that we're already 35 minutes in. So I'm going to keep going for now. My last use case is with the Fairfax County Public School system. They're unique in the fact that every user is an authenticated user because what we built for them was an intranet. And so similarly to the municipality, they have departments and organizations and needed content contributors to be able to work on content with a complex editorial workflow. One thing that is implicit, but I'll say explicitly, is that these were some of the nicest people on the planet. I can't tell you how much of a difference it makes working with people that want to work with you. And the solutions that you can come to when everybody's kind of working together towards the same goal. So I feel really good about what we got to accomplish with the school system. Again, they had a lot of contributors, a couple of unique challenges for this client is that we do have a search API and solar integration. I will say out of box group worked really well with the search API, the ability to just include it as an entity and do all the things that you're used to with Node, which pretty much they're right out of box didn't really need to do anything special to get things indexed into solar. They have some complex workflow requirements, which we're going to talk a little bit more about in a minute. Again, they also really focused on the administration experience. We also migrated content into group. And the migrate module by and large did exactly as what you'd expect since group is an extension of the entity plugin. Pretty straightforward, pretty typical migration stuff worked really well. One difficulty we did run into was this client wanted authenticated users the ability to favorite and subscribe to stuff. The views and its basic nature doesn't want to display more than one entity type on a given view display by default, but basically the end run we did there was to use search API instead. And search API really doesn't have any problem rendering more than one entity type on a particular view display, which is super great. Same thing here also with the SSO via SAML. The SAML implementation was pretty straightforward. If they had exposed more information to us through their HR system, I think we could have done some cool things with relating people automatically to groups and creating groups automatically. This next slide, I just wanted to show quickly how complicated their workflow really was. I spent a few sessions with them gathering requirements about their needs and what kinds of emails they wanted to send and what happened and who could do it, et cetera, so forth. But the really interesting thing about this is how this came together from a group role perspective and a Drupal role perspective. So the custom roles that I created for this client were contributor, reviewer, editor, and department administrator, which do mainly the things they sound like they do. But the interesting thing was because everybody was authenticated, we couldn't use that kind of anonymous outsider paradigm that Deborah was talking about. I had to create some custom Drupal roles, one for member, one for reviewer. And basically, once you became a member of a group, we just wrote a little custom code that added the group member role to your user entity, which gave you the kind of basic administrative experience that you need in order to do lots of things in Drupal, like seeing the administration team and being able to access some pages and et cetera, so forth. So these are some of the customizations that we worked on for FCPS. We created some custom routes much like the municipality use case. We extended the replicate module, which allowed group entities to get replicated effectively. As I already mentioned, there was that Drupal role component. We did the migration, as I also already mentioned, and much like Deborah's use case, we did a lot of work around making group entities view modes pretty. And it's cool because you can bring together, because you're in a group context, all sorts of events and news and information, onto that landing page that gets users to content faster, which is what we all want. So that's all she wrote for us, guys. Let me know what kinds of questions you have. Yeah, I think I want to start off by talking a little bit about, there was a question on whether or not, I think there was the code that I, the custom code that we had for the media module, what is it contributed back? And we didn't contribute it back because it was really just a series of form alters, really, because I think that what really happened was, since the user did not belong to the group, it didn't know where to get the group from. So there was a lot of form alters to determine where you were adding the group, and then you would pull in the group from the content as opposed to the user. So I'll see if I can maybe get that on the GitHub repo as well. I'm not sure if it's something that can really be in the form of a patch. I think it's maybe something, because I think that maybe has to rethink the whole way the group media module works. So some other questions, let's see here. There was, there's one, did you see or did you use out-of-the-box workflow module and content moderation, or was it custom? So we did use the, for the use cases, I was describing, we did use the out-of-box workflow module. The only customizations we really did were tailored to the client. They weren't tailored around groups. They were tailored to the client and so far as the emails needed to go out and some things needed to occur in the background when certain transitions occurred. But we didn't certainly write an entire implementation out-of-box. I definitely leveraged workflow transitions to accomplish a lot of my goals. There's been a couple of top questions around performance too, and I didn't really come across any performance issues around groups, but there's a question on what things or steps to better avoid to do with the group module, and are there any recommendations in regards of the number of group roles and users or content entities assigned not to exceed? Again, and then a related question is how does groups play with the dynamic page cache? Immediate response to that personally. I will say that for that municipality example, we are getting to the building and performance stage now. We're remediating some issues around using Google's Lighthouse Reporting to lighten up the page weight, but we are going to be using flood.io to do actual performance testing as well. If you send me an email with your performance questions, I can follow up with you about what kinds of performance considerations I had to do to make flood.io performance testing happy. Another question was what patch do you use for content moderation roles permissions? I think that that was listed up in the patches slide up there, so when we and all those are linkable and you'll be able to get that patch to be able to have the permissions for those transitions. Let's see here, would it be possible to defer the job of a group's landing page to another entity, like a user or a node? The group landing page is really, you can make it as more of just a back end. You could really make it anything you want for a landing page. I'm not really sure why you would want to direct it to a user, but definitely a specific content type or specific content might actually be a better landing page for a group than using the group view, because then you do have revisions and you can put things in draft mode and things like that. I'd say I would prefer to use, in my experience, I would prefer to use the group entity view mode as the landing page if I could. I totally agree with Deborah that if you need workflow and editorial, you have editorial needs that you do have to take a different route, but I think that the group entity view mode does a great job of working as a landing page for my use cases personally. Okay, so we'd be very interested in eventually seeing your custom code view display, view display code and get how to limit admin content list by group slash permissions. Is that one of the examples? Yeah, I'm going on mute because I don't want to have the echo happen, but here's the GitHub link to where I put those code snippets. Feel free to check out that GitHub and it has those good snippets that I had linked in the presentation. And definitely we'll figure out how to get the slides posted because there are some good links to the contributed modules and the patches. I mean, I don't think that there's any implementation that wouldn't require at least one of the patches. They're pretty useful patches and eventually will be brought into the module, but have not been yet, so you'll need them. Joshua, beat me to the punch. I'll figure out how to get the slides exported and just add to that repo that I just linked so that you can get the presentation. I'm sure that there's going to be a bad camp distribution path as well, but I'll add it to the GitHub. Any last minute questions? I think we're basically at time. Nice seeing familiar faces. Have a nice one, everyone.