Each week, our Vice President of Product shares an email with the company that’s filled with the background story on why Brightspot’s features are the way they are. It’s not just how Brightspot works but why its features were engineered the way they were. Not one to keep secrets, we’re sharing her insights with you here, in a weekly column called “The Whys.” From creating vanity URLs to knowing the difference between a document and an attachment, these posts answer the questions anyone who publishes digital content has likely pondered.
Today we're going to talk about Users and Roles, aka Permissions.
In order to understand the way we defined Users and Roles in Brightspot 4.0, you first need to familiarize yourself with the 3.0 permission system.
1. All / Some / None
OK, so here's how Permissions were configured in Brightspot 3.0:
If you take only one thing from this, let it be this: There were a lot of check boxes. When creating a Role, you had the choice of giving permission to All, None or Some. This setting was applicable to tool areas (like Admin) as well as to Content Types.
“All” and “None” are pretty straightforward—one click by an Admin gave a user access to everything or nothing. The “Some” setting is what introduced a certain level of difficulty.
Take that list of Main Content Types in the screenshot above. There are 22 Main Content Types in that list and (not shown) approximately 70 Miscellaneous Content Types. When you selected Some, the default setting was All. An Admin would then have to click within all 22 of those Main Content Types and all 70+ Miscellaneous Content Types, and then decide whether to set it to All, Some or None.
Let's say you wanted a Role to have access just to Images, Galleries and Modules. You would set those three Types to All and then set the other 89 to None.
It was ... a lot of clicks.
2. Workflow Transitions
Now, let's say you wanted a Role to have access just to Articles, Blog Posts and Galleries, and you were also using Workflows for those Content Types. You didn’t want that Role to be able to publish, just draft and save content. In that case, you'd set everything else to None (another 89 clicks), and set Article, Blog Post and Gallery to Some. Then…
In this case, you'd deselect all the workflow transitions you didn't want your users to have access to—for each Content Type. So that's another 30 or so clicks.
Remember that the 3.0 permissions system was doing its job. It worked. We just weren't doing our Admin users any favors or making their lives any easier.
3. Content Types and Tabs
OK, the last thing you need to understand is under the Tabs drop-down:
Yes, more check boxes. This, in my opinion, was one of the harder things to manage in the 3.0 permissions system. Tabs in this context are the tabs you see on Content Types. On an Article, for example, let's pretend the tabs are Overrides, SEO, Legacy, UI and History. They're probably the same on Gallery and Video. What was difficult about the list above was that it was completely separated from the Content Types the tab appeared on. So, if you weren’t sure which Content Type included the tab "Sidekick," you were in trouble. The other limitation of the old system was that you couldn't deny a user access to the Overrides tab on Article but not on Gallery. Once you unchecked a box next to a tab on that list, it was gone across all Content Types.
Now you have enough historical context on Permissions. Next, I’ll introduce the Brightspot 4.0 permissions system.