 So now we're a minute late. How many of you have used Workbench in Drupal 7, by the way? So, OK. It actually hasn't changed much, and that's good news. Hooray. So we'll go through what we have here. So I am Ken Rickard. My voice seems to be pretty good, but I am struggling with a little case of the Drupal flu. If I actually do collapse, it's because I'm running a mild fever. I work for Palantir.net. We're a web strategy design and development firm based in Chicago. I've been doing Drupal since 4.5. I started in 2004, actually. I maintain both domain access and Workbench access. I was also one of the co-authors of pro-Drupal development for Drupal 7. So I do have some experience in these sorts of things. Ironically, I'm now in charge of sales and marketing. And except for Palantir.net, have not built a Drupal website in like three years. I used to be a day-to-day Drupal developer, but I'm not anymore. So I'll give you a little bit of history about Workbench, what it is, a little bit of module status information. I'm going to do a live demo to show you how it works. Live demos are fun. And a little bit of roadmap stuff, because there's some really interesting things that have happened. I didn't really change this slide. I usually do it for my audience. So Workbench actually comes out of a lot of the stuff that we do in Drupal projects. So at Palantir, we do a lot of work with higher education and government organizations who tend to have very complex org charts and structures. And they tend to like to map their web governance to their org charts. So that's one big thing that we deal with. And so at the end, it's actually at the end of the Drupal 6 cycle. We were in San Francisco in 2009 sitting in someone's hotel room, all the senior engineers at Palantir plotting. We'd been solving the same problems over and over again in Drupal 6 with a sort of combination of a bunch of modules and custom code cobbling it together. And we said we wanted to fix that. So the common things that we went after with Workbench, and when I say Workbench, it's actually a suite of three core modules now, and I'll talk about those as we go. These were really the things we were looking at. You've got people in the organization who have multiple skill levels. Some people want to learn Drupal as much as they can. Some people want to learn as little as possible. Access and permissions, which is where that big org chart comes from. How do you partition the website so that certain people can do certain things and other people can't? Extensible workflow states. Again, we'll talk about that in some detail. And then the big one at the end, which turned out to be really, really hard, modifying published content without going live. And I'll talk about why that's important here too. In terms of the use cases for things and the multiple skill levels, there's a big Drupal learning curve. How many of you have heard the lovely, oh, but WordPress is so much easier, even though it's not? I'll give you my one WordPress rant. So my wife's company has a WordPress site that I moved to Pantheon for her. There are ads in my freaking admin interface. There are ads for WordPress services in the plugins we used to run that website. This makes me very angry. But the learning curve is a big deal. This idea of my content, where are the things that I care about? Where are the things that I want to edit? And you have to understand that for a lot of the websites that we work with, we're talking about hundreds of thousands of pages of content. I said I go way back. The first big website I built was the first, well, we built the first newspaper websites on Drupal and my old job. And the first Drupal 4.6 site we built had a quarter million nodes on it. And that becomes a huge, that editorial workflow, finding the things you care about becomes really, really difficult. Yeah, can you review content before publication? Can you make changes to live content so that those things can be reviewed before the change happens? And his last two, our old CMS did it. And those unstated expectations, right? That idea of, oh, of course it should do X or Y My big advice to you, by the way, if you're going in to do a large project, if you have the opportunity, you can make the opportunity actually. Go and watch people work. Like literally go and sit and watch them use their CMS and make notes. In particular, make notes of the workarounds they use to get around the rules that the CMS tries to oppose on them because those are the big problem points you're gonna wanna solve. So one of the things that we wanted to do is this hierarchical access piece. This idea that certain people have access to certain aspects of the website and can only create content within those silos, right? And so you have, this is by Lovely Museum example. People who are exhibit curators who can only work in that one area, whereas you have a super administrator here, George, who's an editor, who can edit anything that's in here. This is a big deal for a lot of organizations. And what I like about what we did in the workbench space is this is a solved problem. It's actually a very easy problem to implement now too. And then there's this approval workflow stuff, right? This is pretty typical. Have anybody, have any of you been to the workflow initiative stuff, which is gonna go into this too? Pfizer is driving a lot of that workflow initiative and it's really fascinating. If you look at what they're doing, everything that Pfizer publishes on the web has to go through legal review, everything. And sometimes that legal review means, oh, we made a change on page one. We have to edit or review 30 pages that tied a page one to make sure that it doesn't, it's not that change isn't. Altering the context of medical information in a way that violates legal standards. It's very strange. But that's the approval workflow that many people need, right? And of course, this is the approval workflow that Core gives you out of the box, right? And I say this has been a long standing issue. One of the problems we have is we might have a published article that we then need to update, right? But we can't take the live version down. How do you actually do that? It's what we call a forward revision and technically wasn't possible in Drupal 6 or Drupal 7. We actually solved it in 7 and then opened a security hole and then it got closed. In Drupal 8, we actually rewrote some of the code so that forward revisions are actually possible. And a forward revision simply means, yes, the most current version doesn't have to be the live version. For the longest time, Drupal assumed that the most current version was live. It just saved it to the node table and that's where it did all its work. So this kind of workflow is really, really critical for people. The other thing that Workbench sort of does, this is my list of Drupal 6 modules. I said that we used to cobble together solutions for this. There's about 22 modules that we used to use in order to do these things in Drupal and again, we replaced them with three. The reason that we did that is people always used to ask, like, well, why don't you just use this module or this other module? It doesn't workflow do this. Can't you do this with OG? Well, you can. The biggest problem actually is when you use 22 modules for this stuff, you're gonna deal with about 22 different assumptions about workflow. You're gonna deal with 22 different assumptions about help text and language and names of things and that can become very, very confusing because if you've ever seen, you know, Diff module wants to do things in one way and revisions and core wants to do things in another way and that can be very, very confusing. So the idea was to standardize things. So that's the big thing. So, live demo, this is the fun part. We're gonna do this without a net, which is fine because I do this all the time. I just have a standard, this is a stock Drupal 8.2 site that I have put some dummy content in and created one piece of content here. This piece of content is kind of fascinating because I prepped it last night. You can see the tabs across the top, I hope. I could make this bigger. Do I need to make this bigger for folks in the back? Because I have really bad eyesight myself. You're okay? Okay. There's plenty of space up front if you can't see. So yeah, we have view, we have edit draft, we have latest version, delete revisions and devout just because I have devout turned on. So when you've got, this is a node that's in moderation and when you have something in moderation now in 8.2, well, I'm jumping ahead a little bit. We don't use workbench moderation anymore. This is content moderation. This is now in core as an experimental module. Edit draft will take this current version and let you make a new version of it. That latest version, this is the fun part. This is that forward revision that I was talking about where I've made a change, but it's not live. This is waiting for approval. And you can see there's actually moderation steps on here so I can move this to publish. Right now, all I have set up is draft state, published state. There's also an archived state by default, and I'll show you those here in a second, but I can go ahead and just say, okay, let's go ahead and make this. Yay, hello, double. So, very nice, very easy workflow. Let me show you some other things that are built in. Workbench itself, when we talk about workbench, is really just a collection of views and they're a collection of views tied to the user who's currently logged in in order to make things easy to find. You'll notice that we put something up in the task bar at the top. We have menu items there in the left just to help people find stuff, really. These are customizable. There's a little bit more work we have to do with it, but workbench proper doesn't do much at all except for this, which is kind of fun. And then the other piece that's fun, if we go and look at this article, is this access control here. So, we have sections, which we'll just use to say, this is how we declare who can edit what and users can be assigned to sections and then they map directly to the nodes. So, this is editorial access control. The interesting thing to note from a site builder perspective, and sometimes people don't understand why this is the case, the permissions for workbench access sit on top of cores editing permissions. So, number one, you have to have the ability to say, create articles or edit articles. And then we layer on top of that, edit articles tagged with this section, right? So, this permission by itself doesn't actually do anything, but it is a restrictive permission on top of the core stuff. So, really exciting. Now the fun part, because we're in the site building section, I'm gonna show you how this stuff actually works because there are a few, I don't wanna call them quirks. I wanna call them, they're learning aspects. There's things you have to learn to configure because what we've tried to do, I think, and I think we've been pretty successful about it, is we've tried to hit that 80% use case, right? We've also then tried to make the system configurable so that you can go beyond that use case. And I'll show you the two primary examples. Why don't we start with, let's start with access because that's the one that I write and I understand. So, the way that access works is actually really well-suited for Drupal 8. I had to hack some things around in Drupal 7 to make it work right. For those of you who are developers in the room, in Drupal 8, we have this concept of an access scheme and a scheme is simply anything that can declare a hierarchy, right? Because we're assuming that the access control rules follow a hierarchical pattern so that anyone at a higher level has access to anything below it, right? In core, of course, the hierarchies that core ships with our menu and taxonomy. So we ship with default plugins that cover menu and taxonomy. But we use Drupal 8's plugin system to declare scheme handlers, basically. So you have a scheme class and there's actually a base class that does most of the work for you and then you can extend that class if you need to. We have a case for a client right now where we're actually using node reference as the hierarchy scheme. So he's written, one of our developers has written the custom plugin that reads a specific entity reference field. So you can change, I don't recommend doing this on a live site, but you can change which of the schemes you want to use. Within those schemes, again, with taxonomy, it says, well, which vocabularies are eligible to be used? Note that those vocabularies are, you can select multiples, which is great. You can determine whether or not those rules apply to different content types, right? So let's say you have a blog content type that anyone can publish to. You don't need to put access controls on it so you just don't, right? The other thing that, really the reason I show you this is we did not make the assumption that we should force a field on you as a site builder. And this is, I think, important because generally when you're building a site, I mean, menu is pretty obvious, right? In the menu case, we actually do just piggyback on Core's menu form, that's fine. But I'm gonna assume in most cases that if you're building a website, you probably have a taxonomy already. And that taxonomy might map very, very well to your access control rules. So rather than creating a new field, what we allow you to do is say, this is the field I wanna use to judge access, right? So if I went and created, I will do this and it will work and I will be happy. If we go to the content types and say under article, so we wanna use a taxonomy term reference and we'll call it new field. If that, awesome, we'll just let that be limited. Ignore that, that has nothing to do with me. And we'll use this vocabulary, that's great. Now, when I go back, if all this has worked properly and the cache has cleared the way I hope it has. So now I could switch to using new field as the access control field. This is, again, it's a configuration step that might initially look like a pain in the butt for you to do, but it's really to give more power to the site builders, right? So that rather than making an assumption about how you're gonna organize things, I'm gonna assume that in many cases, if you're using a taxonomy, it might, the organizing principle for your governance might be the same as your organizing principle for IA. It doesn't have to be, but it might be. So that's the way this works. Are there questions about this? This is really all you have to configure. There is one other piece that's section assignment. So the section assignment is how you assign editors. And they, again, show you the entire hierarchy and then you have two different ways to assign people. You can assign by role, which is pretty straightforward, or you can assign actual individuals. I will admit, the assigning individuals UI needs a ton of work. In the Drupal 7 version, it used to be an autocomplete. In the Drupal 8 version, I just was getting it out the door, so it's just a checkbox list of every single user in your system. So not really very usable, but that's okay. These, this is what's interesting, actually. These are fields on the user that are forced. It's created for you. There's a hidden field. I can show you account settings. When you install Workbench Access, it, wait, excuse me, that's not quite, no, that is true. When you install Workbench Access, it does automatically install a sections field on the user object and then hides it in the form because there's some complexity around should you allow people who have access to some sections but not others to be able to assign other users to those sections. And I haven't had time to write that in the context of the user form, so I just hit it. You can expose this, but use at your own risk. So that's what Workbench Access does. The interesting piece about Workbench Access, I'll point out, unlike some access control modules, it doesn't do anything to the view state. It doesn't care about view. It only cares about create, edit, and delete. Then that's by design. So if you have questions at any time, I'm happy to answer them. If you have use cases we want to address, I'm happy to try. But let's look now at content moderation. So again, when I jump back to the slide deck portion of the evening, we'll talk about what content moderation is because I assume everyone knows that basically Workbench moderation went into core in the last cycle, hooray. So it's part of 8.2. On the back end it's a little different, but in the front end it's actually identical. So they haven't made any real changes. The only change that they made that is really, really visible is that Workbench moderation by default shipped with the state's draft needs review published and archived, needs review is not shipped with Drupal core. I don't know why that is. It doesn't really matter that much to me. What is interesting is that the archived piece, if you've been following along with the workflow initiative, the archived piece is necessary for the concept of the trash module. So archived means it's a special version of unpublished that says yes, it's unpublished for now, but we might want to bring it back. It's kind of interesting. So when you add a moderation state you can, so I like needs review is what we always do. Review. We're gonna say that's not a published state. It's not gonna be the default revision. When you, this is again the issue of configurable things, whoops, hold on a second. Let me make sure that was in the right order. I think that goes up here so I'll just move it. What happens when you create a new workflow state is there are two things that we have here. We have again moderation states and then we have moderation state transitions and the transitions are where the magic kind of happens because the transitions are moving from state A to state B or state B back. So when you add a new state, you have to go in and then configure the new transitions because there aren't anything by default here under needs review. So you can, in the transition from draft review, draft review, save that. Typically what you would do is something like this. You'd add that and we'd say, we'll call this review and it goes from needs review to save that, there we go. And then for now we just won't, we won't have a transition state for published back. I think it's pretty clear for folks how powerful this is as a system because you can create very complicated workflows very, very quickly. The thing that we really like about work mentioned as a whole from a developer standpoint is it literally took 50 or 60 hours of custom coding out of every single project because we now have workflow models, we now have access control models and it's very easy to just go into the client and say, okay, this is the way this is going to work. Why don't we try it out and see if it's sufficient for your needs? I have seen people get in a lot of trouble trying to mess with these and make really complicated workflows. Generally the four states we have here are perfectly sufficient. Just this concept of here's a draft, here's something I want someone to review. There's some other niceties that we might want but my firm recommendation is keep things simple. I will show you one other thing that you have to be aware of when you are building is that once we have created these new moderation, that's not where I want to be, I want to be here. UX problem, we have people in two parts of the admin menu. Permissions, the thing to note is that when you create new transition states which they're in content moderation now, content moderation, you get moderation permissions for each transition state. So it's important when you create new states to go in and change the status. One of the other nice little things and one of the reasons why, whoa, things got into core, hold on one second. One of the reasons why content moderation went into core is that it does enable some really interesting options that sort of push the boundaries of what their core code assumes. So like the biggest thing we did in the Drupal 8 cycle was allow for forward revisions just by changing how nodes were saved which would have let us do all this in contrib which is great but we also have this view any unpublished content permission which didn't exist in core prior which is a really, really helpful permission. So good to note. The one warning as it stands now, my understanding is that if you install content moderation you cannot uninstall it. So that's a bit of a warning but the idea here is to get it out in a real world use case and that, oh that's right, no the change that they did, that's right, work bench moderation can't be uninstalled right now because there's an issue in core that if you have live data associated to your fields that module can't be uninstalled. They fixed that when they moved it into core, that's correct. So you can uninstall content moderation and we'll talk about the differences between content moderation and work bench moderation here in a second. So I should show you the last thing in the demo. In some respects, I think unlike work bench access which like I said doesn't force a different field on you you can select which field you'd like to use. That's fine. Work bench moderation, what it actually does is it ties into the way things are saved. So your work bench moderation options are gonna show up in the save links here at the bottom but that's not very exciting but it's worth noting. So yeah, what's nice again from a having it in core perspective there's a lot of work to be done here on the revisions tab and how this is gonna be done and having a use case for forward revisions in core is really gonna unblock a lot of that work. So pretty excited. So that was the demo. Hooray, I didn't break anything. Everything worked. We have plenty of time. I'm more than happy to wrap early. That's fine by me. We'll talk a little bit about roadmap. So yeah, roadmap number one, what do we do with work bench moderation? It went into core, hooray. Seven years after we came up with the idea, now it's a core module. I think we did have a vision in the beginning that it would go into core because it's a really useful thing that will help differentiate Drupal in the marketplace. We'll talk about that a little bit and then what's going on with work bench and work bench access. So content moderation, I think you've seen. Hey, it's in Drupal 8.2. That's awesome. I did not change the code links for the original stuff but we talked about this. What is content? Why is it in core? It can improve some core APIs, built-in default workflows. And it's actually foundational. The workflow initiative, have you seen the workspaces stuff that they're doing? So a workspace goes to that Pfizer use case I was explaining. So let's say you change one page but it might change the context. Let's just say you have entity references to it all over your site. So change to one page may affect like 80 other pages. In a workspace, you can assign all 80 of those to a specific workspace. And what the workflow initiative people wanna do is then take that workspace and run it through a moderation queue. So what's fascinating is that content moderation, the way it's written, only applies right now to nodes but it's actually abstracted enough that it could apply to any content entity type. Right, so it's very easy for it to apply to a workspace which is in fact a content entity. So there's a lot of things moving in core right now around standardizing how we handle the save process and standardizing the APIs around workflow and getting content moderation in early helps with that. So it's a very foundational piece. That doesn't quite mean that workbench moderation is dead in contrib for the moment. There's a couple of things that have to be done that are easily done in core or more, excuse me, more easily done in contrib. But I will point out for those of you, is anyone using workbench moderation in production right now? Four or five brave people. I say brave, it's perfectly stable, it's fine. The 8.2 branch, 8.x.2 branch, Tim Millwood is taking over and that's actually gonna be the upgrade path branch to let you transition from workbench moderation to content moderation. For the moment, I'd say stick to workbench moderation, but within the next, I would say three to four months, there'll probably be a pretty direct upgrade path. Workbench, what's going on with that? It's just built with views. There are a couple of little pieces that I haven't figured out how to solve in the Drupal 8 cycle, which essentially is how do you extend it? How do you let people add new views to it? In particular, since it's now gonna be using content moderation and content moderation has extensible workflow states, how do we allow people to add new dashboards to things? Am I gonna use plugins? Is there gonna be some kind of views registry? Is there a UI for it? I just haven't had time to think through those things. If you're at all interested, I'd love to know. Also a question of do they need any kind of additional features? But I mean, workbench itself is really just a series of dashboards, so I'm not terribly concerned with that. There is code, it's an alpha release that I spun up for Drupalcon, New Orleans and haven't touched since. The active stuff is in my GitHub, if you care. But that alpha is perfectly stable-ish. There's nothing really wrong with it. You could duplicate it yourself, though, really. I actually recommend it. I always recommend to people when you're building a site, build editorial interfaces, right? I could show you, we at Palantir.net, which I just built, our homepage is run by a series of node queues, where you can put in things like newest client testimonials or newest case studies. And our marketing person doesn't know Drupal from anything and doesn't know HTML. And so I just put in a dashboard for her that basically says, here's where you go to update these things. And here's where you go to preview these things. And here's where you go to make these changes live. And it really makes things a lot easier to do. Workbench Access, is anyone using this, by the way? Nobody, it's always been the less popular. One person, yay. I love this module. It's one of my little projects, right? Yeah, it actually does solve a very, very good use case. And it's really powerful. The interesting piece, of course, is that while it's using a plugin model, the plugins it returns are giant arrays of dooms still, which is not necessarily good. So there's a question of whether or not I should make the plugin return traversable objects instead, but I don't understand that code, so I haven't really gotten to that. There's also a question of whether or not you should extend it to all entities. That is a fascinating question that I've been ignoring for the moment. You certainly could. I don't know that I have any interest in supporting that. We talked about the user assignment piece, which is just plain ugly, but does work. And this is my embarrassment. It has zero test coverage. So it's an access control module with security implications and no test cases. So that's no good. So that's why it's stuck in alpha, but we're using it in production on a couple of sites. It actually works, it does what it says it should. As they say, what it says on the tin. But that's good. Here's the code. Yeah, it's Workbench Access. It's been on Drupal for a while. You can go to my GitHub. And there's only, I think there's actually only eight issues blocking a stable release. It's actually pretty straightforward. So some of those are just tests. So if you wanna write tests, come find me. I should also point out, I had said this was all hatched in a hotel room seven years ago, and that's true. There's a lot of thanks for the Drupal 8 version. Adam Balsam and John Kennedy actually run the Lightning Initiative for Aquia, and they were also responsible for Aquia's funding of the Drupal 8 Module Acceleration Program, and they selected Workbench Moderation as critical for that. So Aquia provided some funding, and then Adam and John provided some technical leadership, which was really helpful. Larry Garfield, excuse me, and Joe Purcell, when they worked at Palantir, they don't anymore. When they did, they spent most of the spring working on it. Beck White is one of the original architects. Patrick Weston wrote the, he's the one who basically field tested Workbench Access for Drupal 8, and wrote the new plug-in. Robin Barry is one of the original creators. And then Ashley Saiborsky did some interesting work with the user interface, which was really, really helpful for us. Should also thank these folks. Lee Rollins actually did a 75% port of Workbench Moderation before we even got started, which was really helpful. Tim Millwood is the big driver now. Tim's the one who's been working on it in core, and then a whole bunch of other folks who helped out. So really, that's all I've got. It was short. I don't mind. I'm happy to demo new things. I'm happy to sort of, when you go whiteboard some use cases, I'm happy to let y'all go. Happy to have private conversations. We have this space for the next half hour. If you do have a question, please use the microphone. Hey, Ken, this is Peter. Just looking at the core modules, it looks like it creates entities to track workflow states. Yes. Can you maybe just describe how the core system of moderation states actually works on the covers? I think I can. Let me double check something. I believe it's creating config entities, but let me confirm that. We're gonna do some live debugging. How do you know if something creates? It extends from a content entity, so I think they're content entities. Oh, it doesn't? Yeah. I don't know that. That's a question Tim would wanna answer. I'm not sure why they're using content entities. I haven't been involved in the direct production of Workbench Moderation, so I haven't really dug into the code. So I don't think I can answer Peter's question, which is unfortunate. Yeah, I don't have an answer. Sorry. You knew I wouldn't have an answer. No, I thought you'd have the answer. I mean, I'm just looking at it. It looks like somehow there's a content entity that tracks the moderation state, basically it's associated with each node or a piece of content. Yeah, and I don't know why that is. Okay. Tim can answer that question. Tim can definitely answer that question. But that's how it seems to work. You can see a table is basically an entity referenced back to the thing it's tracking the state of. Well, except, but here we have moderation state as, I mean, these are config entities too. Those may be the allowed states. Yeah. As opposed to the state for each piece of content. Oh, but then it's storing the actual state stuff in a content entity. Yeah. That I think is the workaround for the can't delete modules with things in, I think that's what that's for. But yeah, it's a little wacky. That might also have to do with how they wanna tie it to other things. Well, I guess you don't, the config entities don't necessarily scale as well as content entities in theory, right? So you would also probably not wanna have as many config entities as you do nodes. You also can't query a config entity. Yeah, not as easily, yeah. Right. And then it looks. That would be the answer for it, right? Because if, yeah, that's exactly the answer for it. Because if you wanna write a view, if you had seen in the workflow initiative, Tim was showing like a view of what they wanted to do for trash module. And it was like a bundle of like, oh, here's every single entity you've ever moved to the trash. And someone was like, wait, you can't do that now. He's like, yes, you can because content moderation has a table for this stuff. Right. So I think, yeah, that's exactly what it's for. Again, so we hit the roundabout answer to Peter's question. And then the other thing I was looking at, it looks like anything that's sort of in an intermediate state, the revision is unpublished, basically. That's correct. That's why it doesn't show up in your normal views. That's correct. And that's why there's a view all unpublished content. So what happens when you're creating a workflow state, you get to select, is this a published or unpublished state? And anything in that state will then have that. Because Drupal still, this is the problem we've been fighting and Tim addressed this in his talk the other day. Drupal and views in particular still assumes that node status or entity status is a Boolean field, even though it's not. But it is hard coded in numerous, numerous places to assume zero or one. So there are a lot of queries that are like, if greater than zero, so, or if less than one. And so fixing that is a bigger problem. But what I was gonna say, so we got the roundabout answer to Peter's question, which I said originally, I don't know. And the correct answer is why if we have config entities that hold our states and our transitions, why do we then have a content entity that stores that information? And the answer is so we can build views that show you transitions. Which will be really useful when we rehaul the revisions page or revisions tab. Eventually we get to the right answer. Yeah, a practical question when we're bench access, when people create new content. They get the, and you have the section sealed. Yeah. Do they only get the options for which they have the right? Yes. Okay. This I know the answer to, hold on a second. I will show you code. How about that? And then everyone can laugh at my text editor and how large my typeface is. This will be great. I swear in the back you'll be able to read it. It's great, it's awesome. Where do I wanna go? I wanna go here. Troupelay Workbench, that's where I wanna go. I can show you the anatomy of a plugin. That's actually kind of fun. Yeah, so this is the Workbench access, access control hierarchy base. Which it turns out there's like two methods in here you normally have to override in your custom class. Which is great. So let's see if I can find it off the top of my head. Yeah, there's a function, options, config form, that's different. Config submit, that's different. Check entity access. That's where the magic happens. The good news is if you write a plugin you don't have to rewrite this function or this method, which is great. Get entity values, fields, field wave data, disallowed options. There you go. So the disallowed options is about well taking things out that shouldn't be there. And I can't remember off the top of my head. I'd have to look at the interface and see why it's done that way. Why is it done that way? Oops. Remember what I just did. It would make my life easier. Let's open the whole thing. Form node, form alter. Oh, this is a fun function. Yeah, there you go. Add the options hidden from the user silently to the form. This is why I did it as disallowed options. So the issue that he's asking about is how do you restrict the list of things that someone can choose? The challenge there is actually you have the following possible use case. Let's say that I'm able to edit everything on the site and my intern is only able to edit three things on the site. I could assign something to sections that that intern doesn't have access to. So I can't destroy that when that person legitimately edits something in her section. So what I did is we have this yet disallowed options. So what disallowed options says is we're about to present this form to the end user. Tell me which of these sections they can't view and then I store those silently in the form as a hidden value so that I can process them separately. So yeah, you're responsible. It also I think makes autocomplete forms easier to deal with because the autocomplete callback just sort of replaces that stuff. It's just like, oh, here's the answer to your autocomplete, remove these disallowed options. So that's, yeah, I have an answer for that. That's pretty cool. Let me show you one of these plugins just so you can see it. The access control hierarchy plugin. Oh yeah, there's an alter options field function too. Remember what that one, that might be the thing. No, I don't. This is the interface. Yeah, alter options. There's two pieces, excuse me. The disallowed options was easy to abstract because it's almost always an entity reference piece. And so disallowed options is in the base class, the abstract base class that you build a plugin from. But alter options, which is the piece that, alter options is the piece that actually does the work. Disallowed options just returns the list for other purposes, mostly behind the scenes. So when you're writing a plugin like this is the taxonomy plugin, what does it have? It has get tree, which is just the hierarchy tree of the thing. Build tree, which is just a helper method actually because we're doing recursion. Convert parents, which is a helper method here. Get fields, this is an interesting method. Get fields is the piece that says, oh, these are the fields that are configured on this entity that are eligible to be used as access control. So you'll typically have to write one of these, I think. Yeah, alter options you'll have to write, and that's it. So everything else, there's a bunch of magic in the base class that has to do with submits and things like that. But piece of cake for the most part. Other question? The, I guess the use case from what I've seen in the interface at the moment. Is it that an approver or someone who's gonna publish something would have to do each piece, piece by piece, as opposed to there being an interface where they could select, say, five bits that they reviewed and then just say, publish all of those. That's the simple use case. However, building that workflow is actually really easy with views in Drupal 8 because you just, that approval state can be applied to, let me actually, let's actually look and see if that's included in core right now. So what we would expect to see perhaps when I go to this content page is can I actually batch select, no, you can't right now, there's a complication to that. It's one of the reasons why I know content moderation went into core. There's something around, so the lists in this, these are actions and so they're action plug-ins and there are weird behaviors that happen if you try to apply the action plug-in to a group and the condition's not met by some of the elements of that group. But you could very easily make, this is the kind of thing I'm interested in doing in Workbench, right? What you should have here on Workbench and I don't know how we would do it, you should have a tab at the top that's like, needs review, right? And you should have a list that would look something like this, right? That just had everything that was in needs review and it would have checkboxes and it would have a dropdown that says, yeah, go ahead and approve. Yeah, that's actually really easy to do. Well, I think there are some blockers to it but the fundamental pieces are there for it to happen. Thanks. And that's one of the things that workspaces do too because, again, workspaces, their idea is you might have 50 or 500 nodes in a workspace and they're all ready and then the entire workspace gets approved. You showed us, you can use taxonomy and menu as a base. Can you use language? No, but I could show you how to do that pretty quickly. That'd be fun to write, actually. It's interesting, I don't typically, we talk about it as hierarchical access control but that's sort of misleading. It doesn't have to be hierarchical because I mean language is flat, right? It's just a flat list. The plugin system doesn't care that it's flat. It's just we support hierarchies and so it just never occurred to me to write a language one. I'm sorry, I'm American, it never occurs to me to do. It's a use case that we have to deal with a lot. I would love to sit down and plot that out with you, actually. Like I said, I think you could use probably menu as your example. The interesting piece there is language does put a field, there's a default language field on nodes, right? So I'll show you, hold on a second. I'll show you what I'm getting at. In the case of, because we talked about this, in the case of a taxonomy workflow, you can choose what field you wanna use. In the case of a menu workflow, you actually can't because, button first, it only lets you use the default menu field, right? Because core already has a mechanism for this. So core does this for language, right? When you create a piece of content. Yeah, I guess. Yeah, so we just have to figure out how to map that field into the hierarchy stuff, which should be pretty straightforward. And you can, like I said, you can use menu as an example. And so this menu hierarchy, I mean, we have an annotation, we have a get tree function, which in your case would be really, really simple. It's like get languages or whatever that is. You don't even need really the build tree stuff. I mean, because you don't have to traverse a tree. Get fields, that's the key right there. Like, what field do you care about? Okay, alter options, you'd have to write this one. Get entity values, you'd have to write that one. That's just to pull the, what I try to do in the plugin system is make it consistent. So basically what happens when we're checking access control, it just says, hey, does this entity have this assignment, et cetera, et cetera. So each plugin has a get entity values method that just says, oh, you want to know what the hierarchy assignment is for this. Pull this data off the language field here, right? So that I'm not having to write a lot of custom code. You'd write disallowed options, which in this case, I don't think you have anything. This is kind of nasty. This is the hardest part to do and the hardest part to explain. Workbench access supports a section filter and a section field for views and you have to teach views how to join to that table. So this probably isn't very clear and we'd have to mess with it a little bit. But that's it. You could literally clone this into access control hierarchy slash language. I should be happy to commit it. It's perfectly legitimate use case and that would be awesome. Now I have one more thing to do this weekend. Hi, I have a question regarding to language revisions. We had a problem in Drupal 7 because we had to do publish and unpublish revisions per language and what would be the state 408? I know where this question is going and I don't have an answer for it. Tim, again, Tim, no one would mention this. I think this is still a use case that they're trying to work through because you have the problem that the language revision state might be out of sync with the core node revision state and I don't know what they're doing about that. I know they're sprinting about it tomorrow. Okay, thank you. But yeah, literally if you go to one of the sprint rooms and find the workflow initiative people, they would love to point you in the right direction on that. I was gonna say a little aside, I always feel guilty about ignoring the multi-lingual use cases. I asked Dries once, you know, Dries is Belgian. He speaks like three languages. It's like, why did you write Drupal in English, right? Never would have occurred, like WordPress. They bolted on language translation six years later, right? Because an American wrote it. And he said, well, but the web is in English. Drupal's actually had translation support since day one. It's really wild. So here's a thought. Imagine you're at a research institution and you've got multiple labs, which are groups. This is Ben, Ben works for a company that works with labs. So this is not really an imaginary phase. And so now imagine that you've got a committee that whose job it is to review content across all those groups. Right. Initial thoughts is that those committees would also be groups, but it seems like there's a potential use case here for using workspaces within that group context to list all the content that's pending review and then have a workflow state that that committee members could go through. Do you see that as a viable use case or is that kind of a search? That's exactly the use case that we're targeting here. And you actually get to an interesting point. In some respects, workbench access in particular, just like a lightweight version of groups, right? Because it doesn't do any of the privilege escalation or it doesn't have menu functions. It's not gonna do any contextual changes based on just about who can access what as an editor. So the scenario that you're describing is exactly the scenario that we wrote the modules for. So there's no problem using workspaces within a group context? That's a Dick Olson question, but I don't think so. Okay, and then you'd probably have to do some sort of override on the access, some sort of a plugin for the scheme so that you can traverse all of the other groups to moderate that content? Yeah, I think that's right. And it's interesting that when we talk about the workflow initiative stuff, they haven't actually asked me about workbench access at all. I think that's a later phase thing, but. It's a little scary. We know how we would do it, right? It's actually pretty, again, in the code, it's pretty straightforward because, well actually let me look at something. Let's look at a question here. How am I doing things? I apologize, it's been like three months since I even looked at this code, so I'm not sure how I'm doing certain things. Ah, there we go. So I'm doing it the easy way. I'm just choosing the hook node access to control access to things. I think we have hook entity access. I know we have plugins that control entity access, so it wouldn't be hard at all to rewrite this to be just an entity plugin and then say, do our rules apply across different entities? So it's literally like two days of work. I mean, it's just not hard. Yeah. Any other questions? Take off early and get to the lunch line before everyone else. Thanks, everybody. Oh, what? Hello, I have a question about notifications coming from these changes when content goes from, I don't know, to a news review, to a news review. If you can describe a little bit how this was improved, it's improved in Drupal 8 because in Drupal 7 it was a little bit tedious to select all those recipients or create groups or hierarchical people. Right, so the question is about notifications of changes, essentially. I think it depends on how you want to do those notifications. Like there's somebody working on a Drupal 8 port, you might be done by this point actually, I have a workbench email, which will actually send emails on moderation state changes. There's, I'd have to look again. We can look a little bit later unless you guys want me to look at code again. Well, I'm gonna look at code again, hold on. It's one of those things like, I think, oh, come on, they have been taken out. In workbench moderation there was an event handler that would fire during transitions and I'm not sure what they've done with it in core. There are two questions around notifications, essentially. One is, can you assign the entity to someone on state change? Or do you just do that in some global way? Those are two slightly different problems. They're resolvable through the actions, either through the action system or through the, like I said, the event system, but I'm not sure that they have been solved. I do know that someone was working on how do I fire emails when something changes? And we know how to do that, but I'm just not sure how it's supported yet. Thank you. Sorry. What about rules integration? Outside of my scope, I don't deal with rules much. I'm one of those people I think in the minority that doesn't like rules. I just usually find it easier to code those use cases. It should be there. My understanding is that rules in, rules in A ought to be using the action system. And then just writing plug-ins for action should be pretty straightforward. So I mean, I'm looking at, this is what's in content moderation, but I couldn't tell you. That was a longstanding problem in the Drupal 7 version was that people kept asking for rules support and our team was like, but we don't use rules. And so that's only really a problem when people like submit patches with no tests and then you're like, yeah, and it's perfectly legitimate support case. I actually think that because content moderation is in core now, the rules people will just, it's gonna be out of the box supported. Yeah, inside of three or four months. All right, like I said, if you have additional questions, I'm happy to stick around. Thanks everybody. Thank you.