Joomla 4 workflow improvements and functionality requests

[denvarel]

The workflow feature may be a game changer for joomla.

---

Right now, the main contender for complex sites: Drupal V8 and V9, have this workflow feature built-in but is crippled since the Organic Groups Module does not have the workflow module integration. Therefore is working, more or less, exactly like is now in joomla (only a publishing workflow for everybody, more or less complex but for everybody). Is missing something, a concept that i called "User Spaces".
In Drupal 7 the "User Spaces" where possible with the organic groups module and complex workflows where possible. Now, in Drupal 8+ there is no integration between any user groups module and workflows even if big players: like the European Union Commission asked for that feature 2 or 3 years ago.

This may not be exactly a feature request but a more general approach (maybe a project) of this Joomla "workflow" concept. Because is an excellent idea but it should do a lot more than just simple publishing, no matter how many custom steps are involved in this publishing process.

My Guidelines.

---

First of all I will enunciate the guidelines that I follow when I create a complex website for my customers:

• Do not presume that the final user is computer literate. Or intelligent. He must have available the simplest and dumb-proof interface possible, easy as possible to learn and where he cannot screw anything.

• Give to the final average user only the rights that he need. If the final average user have rights to screw something, he will do it. And afterwards he will say that the whole system is bad. Will never be his fault!!!

• The publishing and editing tools must be in frontend. Do not give back-end access to the final average user. Ever. The back-end access should be allowed only for development, maintenance, configuration and such. I see no reason at all to offer back-end access to any user, up to "publisher". "publisher" included.

Workflow general features (my order of importance)

---

The workflows actions should be decoupled entirely from editing view.

The best and most logical UI place for launching workflow's actions in front-end should be from that wheel menu that offers now the dropdown menu with "edit" for logged in users with editing rights.

Actually, in the current Joomla 4.0.0-beta3, the workflows are decoupled from editing view and are accesible from article's list view but only in back-end. In frontend there is some mumbojumbo hiding publishing options code that plays with a lot of display code and rights just to hide the publishing options from publishing tab and replace it with the workflow. Very strange approach in terms of UI. The workflows actions should not be in editing view. The workflow actions should be available in Article's View. As simple as that! Maybe in Category view but this may lead to bulk actions from the user... Well, in category view as well as an option.

Once the workflow is decoupled from the editing view in frontend there will be fixed also the contradictory rights that I have to offer to a user at this moment. Now I have to give editing rights to user group in order to let him access the workflow option. What if the user's role is just a "publisher" without editing rights, not an "editor"? How he will access the actions in frontend if he does not have Edit Rights?

I have in backend settings for:

• permissions for accessing workflow,
• permissions to execute a certain transition
  But are useless while I have to give the usergroup the "edit" permissions even if the workflow is just for changing the Publishing state.

Another good thing of this decoupling is that, with this UI of frontent, a Editor/Publisher can see exactly how the article is displayed for public before he will publish it with two clicks: Wheel/Publish action. In editing view the article is displayed differently as you well know. With the actual Jooomla version, an Editor+Publisher must look at the unpublished article in article's view, enter in editing view, add a picture do some content changes, save and go in Article's view again, check if the picture and content is displayed OK then go back in editing view, choose the Publishing tab/Workflow Publish Action. And again press save... And you where wondering why people choose wordpress :)

The workflows should have "User Spaces".

A "User space" is that concept that allows access and display only certain enities. In Joomla's scenario the "User space" is made from the "articles" from selected "categories" only.

There is already implemented the ACL over "Categories" The only thing left is to integrate "Categories" with workflow's actions. Meaning that there is need for an action of "assign/change" category. The below picture of workflow schema exemplifies why there is need for an "action" of changing category.

The final scope is to give to "Sport Publishers" Group a list of latest "Unpublished" articles from "Sport" category only (actually is a Todo-list) and to "Politic Publishers" group the same thing but with "Unpublished" articles from "Politic News" category only.

For this scope the articles must have a "Attribution" action that will change the article's category from "Raw Materials" to "Sport" and status from "Raw" to "Attributed". And a "Not my field of expertize" action that allows to "Sport Publishers" and "Politic Publishers" to send the article back to the "Not Attributted" stage and "Raw Materials" category. In case someone made a mistake and assigned a football game Article to "Politic News" Category.

The last action is, as, you imagine, the "Publish" action that is available only for the "Publishers" group and is not available for the users that have access to "Raw materials". Have a look at the atachment that describes the workflow

NOTE (quite important) This "Category Change" action can do everything that you can do now with the current publishing workflow and a lot more.

From the above example: All there is need are 2 subcategories of "Sport" and "Politic" that will replace the "Unpublished" articles statuses with "Unpublished Sport News"/"Unpublished Politic News" sub-categories. Unlimited subcategories, with unlimited "pseudo-statuses" can be created and managed perfectly with the existing ACL. After all, what is the "Unpublished" status concept? Is a restriction to view the content for certain user groups. The same functionality may be achieved with a custom "Unpublished Articles" Category and correct ACL for that category.
Don't even think to say: Oh, I have to build a subcategory for each category and that is way too complicated. Isn't faster to have the "unpublished" status? No. Because the current "unpublished" status can be replaced in real word practice with a single global category named "unpublished articles" that have the "Access" set as "Special". Is even better in practice since I don't have to verify all categories in frontend to see if there are or not unpublished articles from my contributors in each one... Like I have to do it now. Do not even think to say: Go in backend and do a filtering :) In real world I have to see how the formatted articles looks in my template not to check how it looks in the Everything-But-Not-WYSIWYG editor. One more reason for people to choose wordpress: Click save and you see it in template, you like it, ok. You don't, press edit... In Joomla is: Go back to the browser's tab where the backend is opened and the filtered article list view is... Wait, which article I was editing?... Back in frontent. Oh! This Article! Back in backend browser's tab... Joomla sucks... Honestly? It does a bit...

In order to achieve the functionality from the above Note there is need for defining "Multiple categories possible destinations" in "Attribution" Action.
When the "Attribution" action is defined it should allow building a list with one or more possible destination category, where the action should place the article.
If the multiple category selection is not implemented in action's settings then will bee need for 2 separate actions "Attribute to Sport" Action and "Attribute to Politic" Action. Thing that is OK-ish for small category numbers. But why do it wrong when it can be done right from the start. (Worth to mention that the list of actions available for user can become quite long so is a lot better to have and manage a single action like: Step one: press "Attribution" action. Step 2: Choose WHERE from the Action's custom defined category list)

Chained and Conditional Transitions

Once there is more than one Transition Type possible, there will be need for automated additional Chained Transitions. Even now there is a small chain: Change the Status -> Send a Message.

Once the Chained Transitions are available the next logical step is to have Conditional Transitions based on Article's properties at the time of transitions. Including Joomla Custom Fields! And Custom Fields may be as well manipulated by actions. Hard to program? Not exactly.

A great idea comes from a response that I have received today from Tassos Marinos.

I ask him, as a developer of great "Advanced Custom Fields" to find a way of building a Content Type as a set of Custom Fields that are not linked to Categories. Therefore, moving Articles across Categories will not left orphans or incomplete, mandatory custom fields. He answered: "Another workaround will be to use no category at all. In that way, the custom field will appear on all articles regardless of the associated category." Voila! Creating an custom field with "All Categories" is actually a Global User Field. So I just created a Global User Field meaning I created a Content Type that remain Available regardless of Category.

It should not be difficult to create transitions associated with Global Custom Fields or actions to manipulate a "Global Custom Field". If is not a Global Custom Field (assigned to all categories), is not available for Transitions or for Actions....

A proper messaging system has to be implemented for Workflows

Sending an e-mail cannot remain the only messaging system for a Transition. For people that work from outside of the organization or for people that look on the website once a day it may be sufficient.
But if you want to build a CRM with Joomla then is obvious that the Employees are users that spend most of the time looking at the same webpage. Why sending them to their email client to check what is going on??? Same for a above average size newspaper redaction. The editors are sitting in the front of their online newspaper. There should be the communications between departments. Not thru the email only!!! Not to mention that the email boxes can be overwhelmed of the Action's messages if there is average activity. Between important emails, customers and business responses, Spam messages and whatever is in that email box, now Joomla pushes also a lot of messages...
Don;t get me wrong, e-mail should be an option but not the only option. There is need to use the Joomla's built-in messaging system, Or a better version of it anyway.

Open Source CMS Contenders

---

Wordpress is overwhelmed by Joomla features anyway. Still there are two points where Joomla fails behind:

Auto-update (this saves the ass of the wordpress big time). This feature have created the legend that Joomla is hack-able. Yep! As much as you can work to keep it secure , if the user do not update it, your work doesn't worth 2 cents. And, as I say somewhere ahead: The user will never say: is my fault, sorry, I will pay for damages The most I can squeeze from the owners is a I didn't update it but my friend who has a Wordpress never need to do that. Joomla sucks. The worst is Is your Fault. You sell me a defective program Believe me I have seen all...

UX A lot of talent is spent on Joomla development but the average user UX is still quite bad. That is because the intricate way to deal with articles, even in frontend the abundance of options make it SCARY for a non-tech user. As I say, going into backend is even scarier. Make a easier live for the webdesigners to keep the backend for initial config and general maintenance only. And offer a sleek and streamlined interface in frontend for the average blogger as much as possible. This Workflow can help the webdesigner to hide a lot of options from frontend. Honestly, my users use "Title" "Content" and "Category" along with a File Upload custom field most of the times. Sure, most of my customers are Governmental and they are lazy by default. But what more do you think a non-tech user is thinking at? Metadata? Rarely... About published/unpublished there not even worth mentioned since a proper approval workflow was non-existing before.

Drupal Is a lot more complex

I was stunned to see that features that they include in core since version 7 are not having same functionality and integrations on version 8 (I'm speaking of Groups/Organic Groups integration with the core Workflow module.) Ok you will say, third party integrations need tome to be adopted. Yes but Drupal8 EOL is in 2021!!! Is already too late to build that integration... Drupal 9 is the active distribution and I wonder if they are not rushing like crazy and leave the community waaay behind. And that integration (Requested by huge players a few years ago, I have seen in their interface that European Commision offered a developer to help building the above mentioned integration but it get no response! A few years ago!!!)

Conclusion

The Workflow is a Great step ahead. But no way in the actual form. Playing with publishing states may be fun as an intelectual exercise but users, usually, do not give 2 cents on publishing states. They always use "Published". Period. And if they will use sometimes another states that workflow must be well implemented and Enforced. The UI-UX must be polished and sticked right in front of users. Like the Apple response to the question: Why you don't give an instruction manual to each Iphone? Becouse we make it so well that you dont need an instruction manual. Is all natural (meaning Dumbproof). AAAA! We like it that way yells the crowd. We are stupid we need a dumb-proof phone interface.

Without UI-UX the users will not give 2 cents on what's behind the frontend and if something goes wrong, guess what:Is Joomla's fault! Wordpress is waaay better and we don't have enough money to hire a Drupal developer that is the pinnacle of the CMS. With it only super-sites are built

[brianteeman]

tagging @bembelimen

[denvarel]

Transitions Rights

On previous request I was mentioning the need for multiple transitions types and how Joomla's right affect the functionality of a, otherwise allowed transition for the "Publishers" Group if they do not have edit rights. In practice, a Publisher cannot access in frontend the transition since that transition is in the editing view. Therefore a Publisher must be as well: editor. For simple workflows this may be acceptable but it will affect the site's user roles significantly making the workflow's design impossible.

I have one solution. Inspired from Joomla's settings override of articles settings with menu settings. Regardless the settings of Article's global options. when a type Category Blog menu element is defined, its settings (Options to be exact) are overriding the already defined ones.

Same thing should happen when an Workflow and an action is setup. Since is possible to setup the rights for each one those rights should override other rights:

Example: A Publishing Workflow is defined and Execute Transitions is allowed for Author, Editor, Publisher Groups.
A transition named Publish Transition is set somewhere in this workflow and Execute Transition is allowed for Editor. (what the transition does is obvious)
Joomla default rights is in this case in conflict with the defined workflow. Joomla does not allow an Editor to publish to but the Publish Transition is set as allowing him to execute the transition. (meaning to publish).
If the transitions are decoupled by the editing view in frontend then the logic should be easy: The site's designer have decided to create that type of transition, therefore an Author can publish an article (not thru the editing view but from outside of it)

Imagine what complex workflows actions can be made. Like adding an image to an article, complete the metadata. and possibilities are endless when I say: Edit Custom Field Value.

*** Drupal logic vs Joomla Logic (Taxonomy vs Category)

In fact, I think that the current workflow idea is too similar with what Drupal has built in core. Like a Drupal user was starting implementing the Workflows logic in Joomla. Well, one of the main difference between joomla and Drupal is the following:

• Joomla has the content organised in categories (oh, how strict :) an article cannot belong to 2 categories in the same time)
• Drupal has the content organized by the taxonomy (oh, what great flexibility. I wonder if I things will not get rapidly out of control having so much flexibility).

And what strikes me right in the face is that he strictness of joomla content categorization is actually a great asset when it comes to workflows. I don't have to rely on such general terms as "unpublished, published, featured deleted", attributes valid for all content types. I have a built-in perfect attribute associated with my article; It's category!!! When I change the category, the article does not exist somewhere else (in another category). The taxonomy does not trick me. I will have new settings for the article from the the destination category settings: New Permissions and a new Access Level.

That is the main reason that make me think that Joomla's current workflows come from a Drupal developer. That developer was so blinded by his "flexibility logic" habits that he cannot imagine that Joomla's content follows other rules. And he implemented a publishing workflow with attributes from Drupal that does almost nothing lucrative in Joomla.

Using Joomla article's attribute: the Category, workflows could change Joomla functionality dramatically!

Having an article moved in another category can change the Access Level and Permissions completely for that article, depending of destination category settings. in Drupal moving a Content type will not change its already defined Permissions.
Joomla does by default what Drupal does not does at all.

And if there is need for taxonomy categorization somewhere in joomla, then usage of keywords is possible.

[bembelimen]

Hello @denvarel
Thank you for your long feedback and sorry for the delayed answer. You have some good points there.

Transition execution frontend

The best and most logical UI place for launching workflow's actions in front-end should be from that wheel menu that offers now the dropdown menu with "edit" for logged in users with editing rights

That's a great idea and shouldn't be that hard, you just have to implement the runTransition method in the frontend controller and then add a link: https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/MVC/Controller/AdminController.php#L433-L474

Remove workflow from frontend edit view

I see your point in removing the workflow at all from the edit view, but that's at the moment not possible for several reasons (e.g. that user expect this information from 3.x, ...)

User Spaces

Refactoring the permission inheritance at all (if I understand your "usre space" correctly) isn't that easy. I agree that the whole permission system needs a refactoring (e.g. #14268 for the performance stuff). This can only be done in a major version (probably J! 5).

Categories

The good thing (in my opinion) from the workflow is, that it's not a publishing workflow anymore. It's some kind of a state machine. That means, you can add all kind of behaviours to transitions. There is a new plugin group "workflow", which holds all this functionality. So if you don't need the publishing behaviour in the workflow, you just disable the plugin.

That leads to the next benefit: if you want to manage categories with the workflow, it's very easy to write a category plugin which takes over the category stuff. As it's a plugin you can (nearly) do whatever you want and implement any behaviour you need.
I know that some people are working on some category plugin for workflow, but I don't know if it will be ever finished.

Chained and Conditional Transitions

I'm not sure, if I correctly understand your "Chained transitions", but it's already possible to add "unlimited" actions to one transition. For example publish + send message. This can be extended with more plugins.

For me "chained transitions" is more a time based approach. For a future version it would be cool to have e.g. something like:

Transition 1 = publish article (executed in 2 days)
Transition 2 = feature article (executed in 4 days)
Transition 3 = unfeature article (executed in 10 days)
Transition 4 = unpublish article (executed in 50 days)

Here is a bit the challenge at the moment, that you need some kind of cronjob (or system plugin) in the system. Something similar like: #29592 could help us there in the future.

Once the Chained Transitions are available the next logical step is to have Conditional Transitions based on Article's properties at the time of transitions. Including Joomla Custom Fields! And Custom Fields may be as well manipulated by actions.

This is solvable with a plugin

Hard to program? Not exactly.

Yep, someone just has to do it :-)

Proper messaging system

I think the current implemented messaging system has to be extended to be more flexible (e.g. frontend access). To offer other sending options in the transition, just a plugin has to be coded.

Auto-update

I think David Jardin & Team are working on update stuff, for the future it is indeed a must have feature.

UX

I agree, that there are several UX issues in Joomla!, but e.g. with overrides you can very easy slim down the frontend article form.

I hope I covered all your (valid) points and could at least answer a few of them.

If you're a programmer and want to help, feel free to get in touch.

[denvarel]

About "User Spaces":
In Joomla "users space" is built in: The Category system. A User Space is nothing more than one or more categories that allow access from a specific User Grup.
A Category is having its own permissions. Moving an article between Categories makes possible to move it between different "User Spaces". A "User Space" can have as well a different workflow;

For example: photo department is included in the Publishing workflow but is having its own forkflow: To add photos.
The Publishing team, if an article does not have a photo, moves the article in Photography department aka "Photography Space" (One or more categories assigned to Photo only). After the article is receiving an appropriate picture, the Photography workflow from "Photography Space", allows moving the article back to "Publishing Space" where is the Publishing Workflow.

All that is missing is the "Move to category" Transition.

[bembelimen]

For the image check, if the intro/full image is set, you could check out this PR: #30421
For the category, as I wrote above, it's no rocket science (but needs a bit more than only "move to category".
I'm in favor of such a functionality...

[denvarel]

I see the frontend as this:

[denvarel]

The Transition action from Graphic Design (current stage) to Fact Check (Target Stage) as this:
A new "Transition action" need to be programmed that allow to upload pictures and is obvious visible once the "Fact Check Transition" link is triggered

[denvarel]

The transition from "Edit" Stage to "Content Review" stage include as well a Transition action that does something. Not only change a article status flag as does now.

[denvarel]

The idea is to offer only the required functionality and features to the user.
Various actions must be available in View "Edit Transition"->"Transition Actions" tab. Right now there is "Publishing State" and "Featuring State" simple flag changers actions available only.
Those action are automatically done once a transition is invoked in Backend and are (kind of) available in frontent, in editing view.

[denvarel]

And this is what I imagine as defining "Chained Transitions". Or "Complex Transition".
Having the transitions listed side by side, as are now is, at most, a proof of concept. How it will be listed a new transition type?