Recognizing Web Content Mismanagement 

Using site hierarchies to manage content contribution teams

I’ve been mulling over an oft-encountered requirement, and I figured it would be alright to jot down my thoughts, even if only to evoke a response. Nothing makes my day like a comment that goes, “Uh, actually, there is a better way to do that.”

Here’s the problem definition. It’s quite typical.

  1. Customer has one site. There will be a lot of content on it.

  2. Customer wants all content to be subject to a workflow.

  3. Here’s the important part. Customer wants different users (or groups of users) to be responsible for different content areas.

    1. When IT content gets edited, the IT content contributors should be the ones participating in the workflow to review/approve it.  When Finance content is edited, the Finance content contributors should be the ones participating in the workflow.

  4. The Problem: How can we address the above when a given asset type (in this case, web content) can only be associated with one workflow? Users who have the content reviewer role will be able to review any and all content. So how, do we accomplish what is in 3(a) above.

Now, this is a no-brainer for anyone who’s really gotten into Liferay’s user and site management. But I’ve noticed that a lot of developers who are heads-down in their work, be it portlet implementation, theme-sculpting or other siloed work, don’t get how this can be addressed usually because they have not found the time to read through the documentation.

It is important for us developers to understand how Liferay’s site and user management work at a fundamental level because a lot of Liferay’s feature sets are built to address scenarios just like this. Now knowing about these fundamentals can result in solutions that often miss key considerations, or worse, reinvent the wheel. And we all know how that can impact our lives.

Let me get to it. Here are three ways to address the above problem. Nothing earth-shattering here.

The First Way

Add smarts to your workflow. We have some fantastic documentation on Liferay workflows that truly demonstrates the sky is the limit. With cleverly defined states and transitions and carefully written Java code running inside <condition> and <assignments> tags, it should be easy to accomplish the above. One approach goes like this:

  • Define a bunch of Regular Roles, one for each team. They don’t have to have any permissions. They would just be marker roles. E.g. Finance Reviewer, IT Reviewer, etc.

  • Assign users these roles as needed.

  • Use categories or tags or custom fields to organize your content in some standard conventional way. E.g. Finance content has the category Finance.

  • In your workflow, write the Java you need to examine the content’s category and then assigns the content item to the corresponding marker role. if category == Finance then role = Finance Reviewer

Here is some documentation (with code) describing this exact scenario.

Pros

  • One site to have it all. One workflow to rule them all.

  • Ultimate developer flexibility. Do whatever you need to. Just code it up.

Cons

  • Ultimate developer flexibility. Do whatever you need to. Just code it up.

This can be a problem. Think about when a developer leaves, and has not really transitioned his skills or knowledge to anyone else on the team. The ramp-up time for someone new to all this can be worrisome.  Add to that the possibility you have about 30-40 teams, hence 30-40 content areas and reviewer roles. Now, maybe the developer followed clever coding conventions so what would have been 500 lines of code got done in 50. But that sort of cleverness is only going to make it harder for the next guy to unravel what is really going on. Add to that any special handling for some of those roles. Anyway, you can use your imagination to come up with scary scenarios.

So, am I belittling the script soup that comes with the workflow en·trée. Far from it. I think it’s delicious, if served in small portions. Hence the next two sections.

The Second Way - A Site Hierarchy

Yes. Define a hierarchy of Sites.

  • The parent site at the top is the main site. The parent site will have all the necessary pages containing a meaningful combination of Web Content Display portlet instances and Asset Publisher portlet instances.

  • The parent site may have some content, or none at all. The purpose of the parent site is to be. And a bit more, to serve as a coming-together ground for content from all the child sites.

  • Each child site reflects a team. Of course, each has its own content repository.

  • Site members of the child site contribute content.

  • Each child site still uses the same workflow that all its sibling sites use. But remember: each child site has its own Site Content Reviewer role. So, only members of the child site are candidates for reviewing content in it.

So, all that requirement noise from The First Way, such as Finance content must be reviewed by a Finance reviewer, gets muted.

  • We have a Finance site with users. Some of them are content reviewers. The workflows just work.

  • And when we do need some smarts added to the workflows via scripts, we add those in. E.g. if the content has a category Confidential, assign it to the specific user in this site having the category Department Head.

Small portions help avoid bloating.

The child sites may have pages with various content portlets on them, but none of the pages are served outside of the child site. So, we have some pretty sweet insulation here. It should be pretty clear by now what the portal architects had in mind.

The Third Way - An Organization Hierarchy

You remember the Users and Organizations section in the Control Panel. There really is an Organizations tab on that screen.

Define a hierarchy of Organizations that reflects the organization structure of the enterprise, more or less.

What is an Organization anyway? It’s basically a way to group users into an organization unit. Departments can translate well to Organizations. See the this awesome wiki article on Organizations, and how they’re different from User Groups.

https://dev.liferay.com/en/discover/portal/-/knowledge_base/7-1/organizations

Here are the salient points.

  • An Organization can be assigned users - that’s the whole point.

  • Each Organization can have an Organization Administrator designated for it. These privileged users can add users to the Organization or edit information for the existing ones, or remove them.

  • When you define an organization, Liferay gives you an option to Create a site for it.

    • So, if you do that for all the organizations in your hierarchy, you get an implicit Site hierarchy (much like The Second Way) wherein the Organization Administrator is, implicitly, the Site Administrator.

And with that, everything we said in The Second Way comes into play. The Third Way is essentially the Second Way with Organizations in the mix.

Now, I’ve noticed a few points of interest with an Organization hierarchy owing to the implicitness of the site associated with it (i.e. if one was chosen to be created). But, I’m not going to bring any of that up in this post because I don’t think they pose practical problems. I’m hoping someone will call out what they believe are the real problems, if any.

After all, this, like everything else, is just an elaborate exercise to bring us the words, “Uh, actually, there is a better way to do that.”

Blogs

Note that the first way is typically error prone.  User authors content but forgets to assign necessary tag/category or assigns the wrong values. The second and third options both work and they give each area their own space to create and maintain content. This, however, can be a con as you'll end up with some depts actively maintaining and creating content while others will let their content get stale. Another benefit for the second and third options is that the depts can also have a private space for their people to cover things which only their folks should be seeing. Of the second and third options, I tend to lean towards the second.  The organizational aspect can lock users into their one area whereas site membership can be a little more inclusive for users outside of their place in the organizational hierarchy.  While the lines and relationships in an org chart are clear, the lines around a department site, even from a management or content creation perspective, are often variable and fluid.

Thank you for articulating all that. It gives me a few more angles to consider, esp. the decision points around organization versus site hierarchies.