please can you be consistent in your code and ensure that you always use quotename and not a mix of qn and quotename

as we discussed in germany i think the ui is overly complicated and you should take a look at how drupal does workflow and content moderation see https://www.youtube.com/watch?v=8R2qiFMU8v8

the only thing they and this pr is missing is any form of notification system. eg if my workflow requires notification of an article that i should make an action on then i should be told about it (note that #20162 should make this easier).

I wrote some other thoughts about workflow concepts here https://brian.teeman.net/joomla/886-content-workflow-in-joomla

@brianteeman if you look into the "Content - Joomla" plugin, you can activate email notification (+ activate it in your user settings, that you want notifications)

@bembelimen can you clarify please if the outstanding issues on your repo have been addressed. makes things complicated to work out if something is a known issue or not.

@brianteeman if you look into the "Content - Joomla" plugin, you can activate email notification (+ activate it in your user settings, that you want notifications)

I am well aware of that or i wouldnt have fixed the email notification system in #20162
However all it will do is to send EVERYONE who has recieve system emails set to on with the notification.

In a true workflow system the notification should be sent according to the transition - see the section Selective notification in my blog post and the comments as they all refer to this. Without it then there is no point in having a workflow

Thanks @brianteeman for your input, yes the messages should (and are) selective: https://github.com/bembelimen/joomla-cms/blob/publishing-workflow/plugins/content/joomla/joomla.php#L372-L375

I don't know if you all have seen it, but take a look at Symfony's Workflow class. Our system doesn't have to be anywhere near as "busy" as that, but it has some features that I'm really not seeing in place here right now:

• The ability to check that a transition can be made
• Event hooks for various points in the workflow process (the transitions themselves and checking if a transition can be made being the important ones, Symfony provides an AuditTrail event listener and that is a perfect example of the type of capability that having a hook system would enable

As is, this is really a content workflow manager (indicated by the "hardcoded" conditions; published, unpublished, trashed). Do we want to limit workflows in Joomla to only content or should we abstract this a level higher and have a generic workflow or state machine system in place (that the content workflow here would inherently extend)? An example would be a platform where a user's account would need to go through some form of validation process (so it would have a workflow where it transitions New -> Provisional -> Approved).

@mbabker thanks for your comment.
There are two layers in the workflow:
The states and the conditions.
The states are "virtual elements" which the user, who push some item though the assigned workflow, sees in his dropdown (or whereever he can trigger the transition). States do not indicate anything on the page, they just names. So for your user validation we would have the following states: New, Provisional, Approved

Conditions now define the "visibility" (sorry, I don't know a better word at the moment). Items can have three conditions:

1. they are published/active/available
2. they are unpublished/inactive/not available
3. they are trashed

And now we have the link here: we give "New" and "Provisional" the condition "unpublished" and "Approved" the condition "published". So we have the user validation process + the user can e.g. log in only when he/she/it is approved.

So I don't think, this is a "content only" workflow machine.

It's that condition thing that makes me think this is heavily content oriented. I've done work on other platforms with state machines and that condition logic doesn't exist in a general purpose system (one of the common ones I've dealt with is ecommerce and representing the status of a user's order, that wouldn't have these types of conditions).

Depends,
All states would be published, beside if you trash the order, then this state would have the condition "trashed". If you disable the order, the state would have the condition "unpublished", so the user cannot access it anymore.

Well sure, you can design workflows ignoring the conditions. But I really think the UI and data model here sets a precedent. There isn't anything wrong with having content oriented workflows in place, but I think this condition system and how it directly relates to what would be considered a publishing state promotes this system very heavily as a content workflow system and will influence how it is adopted and used by the ecosystem.

Don't know if it'll help, but I installed this through the patch tester component on a fresh joomla 4 install and I got this error :

Error: 0 Argument 1 passed to Joomla\Utilities\ArrayHelper::getColumn() must be of the type array, boolean given, called in /administrator/components/com_content/Model/ArticlesModel.php on line 458

PHP 7.2.0

Hello @ghazal, thanks for testing this PR. Did you reinstall the Joomla! system? Because the workflow adds new tables. (just delete the configuration.php and start the installation again)

Did exactly as you said:
*deleted configuration.php
*reinstalled the site

Got this new error:
Error: 500 Table mytestsite.bnhoc_workflow_associations doesn't exist

Additionally, most of the administrator backend links lost "administrator" in the URL,
like in:

/index.php?option=com_menus&view=menu&layout=edit

But weren't we supposed to test this through your version (of joomla4) ?

BTW : I fixed the DB through Manage-> Database

@bembelimen same problem as @ghazal I try use patch tester.

Now I will install joomla with workflow from your branch and see how it works. After reading the description and viewing the demonstration, I have suspicions that this is not what I expected from the workflow in joomla. But about this after testing.

I have one question you have blocked the extension? That it can not be deleted or disabled. After all, judging by the code without it, com_content will not work

After install joomla with workflow in administrator/index.php?option=com_content

3065 Expression #1 of ORDER BY clause is not in SELECT list, references column 'joomla_4wf.w.ordering' which is not in SELECT list; this is incompatible with DISTINCT 

@Septdir thanks for the idea, I protected the extension now.

@bembelimen debug from administrator/index.php?option=com_content

Hi @Septdir I updated the select, could you kindly check, if your error is fixed? Thx

I made a hotfix and finally was able to use it, as I thought it is not what I would like to see in Joomla. More than that, I would say that I am very disappointed.

Everything stated below is my POV so @bembelimen I would like to apologize in advance, you have done a great job, and I will now criticize it.

In addition, I will use google translate, so the translation may not be accurate

General impressions.

Firstly, it's not a user-friendly interface; moreover, it is not intuitively understandable. And you have to multiply unnecessary actions. For example, to add State I need to go to Workflow to see there manage to click on it create state then go back and create a Transition, at least you could add the Create Transition button to State

Secondly, if you really wanted to create Workflow just for the sake of publish / unpublish, then, frankly, there was no need for it. Now in Workflow, the user needs to perform 3 actions instead of one.

Third, at first I thought that I could register my state, for example state = 5, but alas not enough that workflow is connected to the state column so it's impossible to write your values ​​either.

Fourthly, why does the workflow exclude the old state field? An elementary example. One article I need to immediately publish another

It turns out that in fact this workflow is needed to reduce the number of administrator errors. No more. And in fact workflow do that to automate and reduce actions.

As I see it

The thought that is below is just my thoughts. But I do not have enough time or skills to even try to implement them.

The most important com_workflow should be disabled. If I do not want to use it, I should be able to turn it off

I have two visions of what workflow can be.

First vision

The first is to focus only on com_content, then you can multiply the purely possible transitions many times. At the moment, as they can not be called, only using the column state can be only 12 actions. But the possible actions are not limited to the state in com_content is featured, category, access, tags and of course permission. Variations with their use can be countless. Then workflow will become really necessary tools in the administrator's arsenal.

Second vision

The second is go far beyond com_content, but it will be many times more complicated.

I would call such a system Tasks and Actions and I'm not sure if it fits the definition of WorkFlow.

Implementation can be something like this.

Any developer. Creates say helper in which it lists all possible Actions. For example, take the two components com_users and com_content

• [com_users] Block user
• [com_users] Set user group
• [com_users] Delete user
• [com_content] Change state (publish / unpublish / trashed)
• [com_content] Delete item
• [com_content] Change category
• [con_content] Add tag
• [com_content] Change access

This is only a small part of the possible actions. Now the Tasks example

• Name: Spamer
• Show in: com_users
• Actions:
  [com_users] Block user
  [com_content] Change state (unpublish where created_by = user_id)
  [com_content] Change access (Super users where created_by = user_id)
  [com_content] Change category (Spam items where created_by = user_id)

In this case, the number of Actions can be increased with the help of plugins.

I would be very glad to see such a system. Moreover, in my humble opinion, this system could become one of the reasons to choose Joomla as a CMS on the site

P.S Actually, in the second version, I can offer many more ideas and an example of how they can be implemented, which came up last night. But as I wrote at the very beginning, I simply do not have the necessary amount of time and skills to implement them.

@bembelimen

Hi @Septdir I updated the select, could you kindly check, if your error is fixed? Thx

Yes, now I can open articles without errors & warnings

Hi @Septdir you can disable the workflow in the options.

@bembelimen No. Because the code shows that this is just a hiding the menu item.

I'm committed to shutting down workflow should mean that I quietly delete it to remove its tables and com_content will work.

As for example com_fileds, I can turn them off without harming the site

If you turn off com_fields, then it also just disable the menu entry. Created fields are still visible and available. We took over the handling of com_fields...

@bembelimen If to be more exact then if to do disconnection it is necessary to write different requests in the database.
What if the component is disabled. These lines became standard and as in the forms was the standard state

You hide fields because once they are setup you may not need to create any more.
The same would be true for workflow

You cannot disable categories because other components require it

Sorry but I just dont get this. From what I can see it is overly complicated and the requirement to add a new "state" to every item just to make this work means that we will need to change all existing components, modules and plugins. Touching so many existing files is a big red danger light to me. As explained before I just dont get why you have to create a new table "workflow_states" when we have a perfectly usable states field already.

To me this just takes the workflow/moderation model from drupal and tries to apply it to joomla. But drupal is different in that it didnt already have states. So instead of wiping out all the existing states and all the code that takes advantage of it you should be building on top of the existing states. In other words we already have the required code for workflow - all we are missing is the code that controls the moderation.

Not writing any more because I already wrote it 1 year ago https://brian.teeman.net/joomla/886-content-workflow-in-joomla

Hi Brian,

thanks for your opinion.
in the first version, we had exactly this: we took the state fields etc. and build on top of the current model. But then we had a big problem: all extensions would break, when there are new IDs (for new states). But we need B/C. So we had to find a solution here.
Secondly we wanted to unify the workflow proccess, so every extension can use this functionality without much effort.
Thirdly this workflow DOES NOT change the create/edit permission of items, it just extends the publish function itself. Access management is planned in the next stage of expansion. But preparing for that, we need something where we can append the access stuff (=> the states), so every state has its own ID and we're at point 1 again.

The solution was this "workflow_states" table. With this table we have the generic solution, so the workflow is usable for every extension. On the other hand we're let the old state field in the content and deprecate it. The workflow updates the old state accordingly the old values (1, 0, -2) for B/C reasons. In some future versions this can be removed and we can rely on the new workflow only.
And with this structure we're fully flexible to extend the functionality bit by bit without breaking anything.

As you can see we had here some limitations regarding B/C and also wanted a solution which is no dead end somewhere in the future.

Edit: the next step (which I'm currently working on) is the abstraction of the workflow into a library with constants instead of hardcode numbers (0, 1, -2)

you do not need new states. what is the use case for a new state?

States are used with the transitions - you do not need to create new states for that to work. transitions are not about changing the state they should be about moving along the publication tree

example workflow

That's what happens in the new Workflow. But as I pointed in my list above, we need something where we can add the access stuff, the current "state in the publication tree" and so on.

Perhaps the name "state" is missleading here. I try to explain it in another way:

We have four entities in the workflow:

• The workflow itself: that's just a container where all the other entities are grouped
• States: states does not have anything to do with the current "state" (Published/Unpublished) means the 1, 0, -2. They are now "virtual" names, like "New", "Graphics Created", "Legal Approved", "Published". Here will be (in the future) the decision, what action the current user can make with the item (which has this state)
• Conditions: conditions are the "old states": they determinateif the item with state X is visible (published) or not (unpublished) or in the bin (trashed).
• Transitions: transitions are the "change" from one state to another, here we have the permissions, who can push the state

So to sum it up, our structure is for states:
id | name | condition (published/unpublished/trashed)

The structure for transitions:
id | name | asset_id

So in fact, we don't change the "old states" (that's the reason why we can be B/C so easy and always can update the old "state" field). But now the "old states" are called "conditions".

With this structure, we have one big advantage: we can have, depending on the user rights, different "flows" for one article. For example could be an article, which is reviewed by trainees, who share proof reading, image creation etc. use: "New => proof readed/needs image => image added/needs review => ready for publishing => published" but on the same time if you have a person who can proof read and adds images you can give them just: "New => ready for publishing => published". So states can be reused, different flows can be implemented but at the end we just have:

| Action | state | workflow |
| Create article | unpublished | Notify Graphics |
| Graphics Created | unpublished | Notify Legal |
| Legal Approved | unpublished | Notify Publisher |
| Published | published | Optionally notify subscribed users |

(if we want)

So when you say "state" you really mean "step or stage" in the workflow?

and when you say "condition" you mean "state" ?

confusing much?

to create the following workflow
create ->add graphic->legal approve->editor
the state goes from
0->0->0->1
and what you need to add to that is the moderation part to process the movement between "the steps" which is the part you call "transitions" aka an acl check to see what "team" the user is in and what "movement" they are allowed to make

Yes, I agree, on a developer view it's confusing. The reason why we did that was: on a end user view the old "published, unpublished, trashed" are states, but in fact they are conditions, how the article should behave.

Now if we would stay with this old norm, the user would push "workflow items" and not states anymore (because the states are "hidden features" of the item). That's why we called this "hidden features" now "conditions" and the user still change (in his/her point of view) "states" and not some abstract "workflow items".

so let's assume your workflow:
create (0) => add graphic (0) => legal approve (0) => editor (I guess published) (1)

Then we would have the following structure:

old publishing | new publishing | example | functionality

hardcode language string | states  | created/needs review/published | just display for the end user
states | conditions | published/unpublished/trashed | determinate the "visible" condition of the item
was true/false flag from core.edit.state | transitions | proffread/publish/approved | determinate who can move between "the steps"

I hope this table is somehow readable.

The idea is, that the end user (after the workflow is set up) never gets in touch with all the transitions, conditions or the workflow itself. He/She just act like in Joomla! 3.x on states. To reach this point, we had to abstract the layer for creating the workflow itself. That has the advantage, that we can add all the good stuff over time and (at least I hope so) never have to break B/C.

But I also fully agree with you, that setting up the workflow itself needs at the moment a good imagination skill. And for this point I hoped to get ideas in this PR. In my opinion we need this database structure to be prepared for the future, the question now is: how can we offer this complicate structure in a easy way....

i still say that the reason you cant find an easy to use way for the end user to do all this is because the system that you have designed is too complicated and that with this architecture it will never be possible to make it usable

The easy way for the end user is already there....for end user nothing changes, he/she operates with the "status dropdown" in the article/whatever.

I have some ideas about the set up part, which improves usability a lot...so I don't see it unsolvable...we'll see...

First the basics have to be improved

@bembelimen
You are in many respects correct, however there are those factors which you do not consider.
At first for users who are used to the old system (published \ unpulished) workflow will seem to be a complication of the already familiar process

Secondly, on many sites, workflow is not needed. Articles are published immediately, or immediately removed from the publication, because they are added and edited by one person. as it seems to me most of these sites.

Thirdly, your current version of workflow can not be combined with com_users and without them there is no sense in developing a system designed for integration with other components.

But if you want to further develop your approach, then that in my opinion needs to be done.

1. It is necessary to remove wokflow and standard models for example from ArticleModel.php components should work without them. You can change state or filter articles using your model.
2. The integration of the workfow with any component should be done either through an additional helper (for example, an association) or via a plugin (in this case there is a small problem with filtering, but its solution will further extend the capabilities of the creators of plug-ins).
3. You do not need to hide or replace the old state field. The administrator should be able to change state without unnecessary actions. If the administrator needs to deny access to the field and leave only workflow, then he can simply change the parametercan edit state
4. As I wrote earlier. The workflow component should be easily disconnected. Maybe even by default it should be turned off in com_content, as I already wrote in my opinion simple sites such as personal blogs, much more than sites where articles are created by ordinary users, or articles require different steps for publication.
5. Better at once besides the change of state add something else. For example, access orfeatured

P.S you can see how the workflow is implemented in dupal and compare the functionality.

P.S you can see how the workflow is implemented in dupal and compare the functionality.

This is what I have been asking since the beginning. Just look at this and see how easy it is for a user to deal with a complex isue

https://www.youtube.com/watch?v=8R2qiFMU8v8

@bembelimen

The easy way for the end user is already there....for end user nothing changes, he/she operates with the "status dropdown" in the article/whatever.

The proposed system is too complicated, even it took me about 30 minutes to develop. Although I consider myself a confident user of Joomla and extension developer,

I would not like to say this directly, but I'd rather say, the system you proposed is not Workflow, it's the same old state, it's only 3 times harder to be able to take steps and filter on them.

Workflow is primarily an automation and simplification process. And you have the complication of the function publish \ unpublish

In addition, there are huge problems with the interface. He, too, simply does not understand.

For example, you can output the workflow in the form of radio and over the state field.

Similarly, if you want to do workflow for other extensions than com_content, then it makes sense to display its views without reference to the extension.
That the administrator could see all possible actions not only in com_content.

And many more things. I apologize if I was rude. Just you just need to imagine how to teach a beginner to use workflow and explain what it's for, so it's scary.

@brianteeman This of course is also important, but for me the functionality itself is more important. Even if the setting is difficult, but if I'm an administrator, I can set it up to make it easier and more automated for content managers to work, I'll be happy.

The simple example.

• sate = 1
• featured = 1

This will publish the article and display it on the home page.

If we add to this the category change and access, then the number of actions will be huge, and then it really will be a useful tool. And if you can integrate with other components, regardless of the structure of the database table, then as I wrote earlier, this can be one of the reasons for choosing Joomla as a CMS. Just imagine how cute is the CMS in which anyone can customize Workflow so that they can perform actions "in one click" no matter what site it is. Shop or Personal Blog or a huge Portal with many different components.

But the creation of such a system requires a lot of time and of course this is beyond the power of one person.

There is power in simplicity
If it takes me hours or days as an experienced user to use your workflow then I am simply not only not going to use the option I am not going to use joomla

@brianteeman I agree. In this case, simplicity will be a very important factor. In many ways, the simplicity depends on the interface.

the interface is only part of it. If the concept is too hard then it really doesnt matter what the interface is.

@brianteeman

There is nothing difficult in the concept I proposed (see above Tasks and Actions).

By the way, in drupal workflow does not look simple and takes time to master it.

@Septdir no problem, you're not rude, the PR is here to be discussed. But I'm just at the run and will answer you in details later, if this is OK.

https://www.youtube.com/watch?v=8R2qiFMU8v8

I know this video and it shows the usage of an existing workflow; they don't create a workflow from scratch, they just use the one which is delivered. So it's hard to compare the "set up" proccess we're talking here about and the end user "status change". If I compare the structure, they have the same elements: states and transitions and at the end, they change the status in the article. So at the end I see no difference in the end user handling.

The history function is already in Joomla! but in a way, that there are no permission attached. So if you can edit, you update the latest version, that's it. That means, if we want to attach the history function to the workflow (which is possible) we need a new permission action for history and have to rewrite the history handling.

To be honest, that is the way it should work, but for that we would have to rewrite the permissions at all (user can edit items with state x), rewrite the custom fields (and all other fields) permissions. So to decouple the permissions completly from the item (here "article") and moves it to the workflow respectively split it up to different places.
Sadly Joomla! is not structured in this way, this would break and as I said before, we have to take one step after another.

@bembelimen

To be honest, that is the way it should work, but for that we would have to rewrite the permissions at all

I will quote one phrase

Take one step backward to take two steps forward

We are talking about joomla 4 so even cardinal core changes can be made. Especially for something useful and for something new. But if we are talking about workflow, then, as I said no one, I should be able to disconnect it without any harm to the site.

Many people are far from web development, although the developers themselves see J4 no more than J3 with a new interface. Of course, you can explain to people and list all the changes and optimizations, but in fact J4 looks like this. But you want something more. And maybe Workflow will be able to change something, but not in the form in which it is proposed.

details later

Here on github sit and read those people who can easily imagine how it will look and wait until the functional is finalized in a later version of joomla

However, most users are not. And if they immediately betray only what is now. And it is the change of state, even in a slightly modified version. It is unlikely that they will like it and then you can safely put a cross on the workflow for a long time. And some will completely give up Joomla. Therefore, one must be extremely cautious.

1. the workflow should be something you opt to add to a specific component or even subset. It should not be something that applies globally.
2. just because we can make a breaking change doesn't mean we have to. we need to keep all breaking changes to the absolute minimum

Below you can see three different workflow scenarios. Each of which can be achieved using the current ACL, usergroups and States.

All that is needed for this is

1. interface to create the scenarios
2. notification to the next usergroup in the sequence
3. UI to move the item forward in the sequence (or even to send it back)

A Workflow extension needs

1. States. These are something like 'draft', 'published', 'featured', 'archived' or 'trashed', just to name those we already know inside Joomla. The extension must allow you to add other states as you need them. The states (intrinsicly) contain information about the visibility. Content moderation as shown in the Drupal video is out of the scope of a Workflow extension.

2. Transitions. They define (and name) the possible state changes. The extension must allow you to define transitions from one state to another as you need them. Transitions are access controlled

3. Workflows. Although you might only need one workflow in many cases, a Workflow extension must allow you to define different workflows, fx. for handling an employee's blog post and a customer's blog post differently.

4. If the workflow extension is intended to work with any other component, it additionally needs a map storing the states for the items.

That is actually the basic design of @bembelimen's proposal, which is clean and good architecture so far.

The only problem I see is that it "pollutes" every extension with its code (105 files changed/added), which is not very clean or desirable.

My suggestion to solve that is introduce a step to prepare for this extension.
Extract all the publishing/trashing/featuring/... stuff from the components into a "WorkflowLight" component, creating a workflow interface during that process.
Add WorkflowLight to the core. It is just refactoring and not changing any existing functionality (although it will change the API).

Next, refactor this PR to implement the exactly same interface, so "WorkflowLight" and "Workflow" are interchangeable (from a component's point of view).

As already stated I do not see why there will ever be a need for any additional states. It is this desire for extra states that pollutes" every extension with its code (105 files changed/added),

Your suggestion for a "workflow light" will still require every extension to be updated but this time with code removal not code addition

I do not see why there will ever be a need for any additional states

That might be because you're a One Man Show. In every other scenario additional states are very useful. Ever heard about the Four Eyes Principle? Current Joomla has no ability to enforce that. In some companies, articles need to be approved by several departments before they can be published. Or, if you create forms, you have to make sure they are GDPR compliant, ideally by letting your Data Protection Officer approve them. Unlike you, I can imagine a lot of different scenarios needing an ACL supported workflow with user defineable states.

And, yes, "WorkflowLight" would require changes in order to provide a proper API (we have exactly none now). But it would just add the API, not change the functionality or the database layout, so it is much easier to maintain and to replace with a more sophisticated solution like this PR.

Please read what I have already written before making comments about me being a one man show. I manage sites that have hundreds of editors. I have already described the workflow you have used as an example. It does not need any new states to achieve an acl workflow as you describe and as I had already described.

The workflow controls the act of moving an item through a process. There is no need for a new state to achieve that. I paste again an example of a workflow without the need for any new states.

The state describes the visibility of an item and nothing more - you do not need to create a new state to say it is still invisible but for a different user. In these examples you define steps - each step has a start and end state, a start and end usergroup, and a sequence defining where it is in the workflow.

So once again please explain why you need a new state.

What you propose and what @bembelimen propose both fundamentally require a complete change in the way that all extensions and modules work. (He adds and you take away and abstract).

@mbabker

But it would just add the API, not change the functionality or the database layout

Workflow even in the future should not modify the database or the standard model

Workflow should be completely autonomous and if it is not needed, the user should be able to easily disable it.

There is still such an idea. Workflow can be released as a separate component. And only then include it in the core

@Septdir that's completely correct. But this proposal would not allow that to happen at all due the faulty assumption that you need to have the ability to add new states :(

@brianteeman
In fact, you do not need to add a new state

Example

• Step 1: Aprove content published = 0
• Step 2: Aprove images published = 0
• Step 3: Publishing published = 1
• Step 4: Popular published = 1 + featured = 1

That is in workflow it is possible and it is necessary to use simply that that is. Alternatively, by making an additional query in onContentAfterSave

And if the group of users forbid can edit state, then they can not change published without workflow. But they will always see whether the article is published

But for implementation via workflow through the plugin, you need an event to change the query, otherwise you can not filter without changing the model

About this event / trigger is asked about once a year

@brianteeman, you're just hiding the state behind the group (Group Start/Group End), losing the ability to define the kind of task expected from that group. The proposed structure in this PR is way more flexible in that regard.

@Septdir, Workflow is needed, as it already is part of the core in a very unflexible implementation (publish/unpublish/trash/archive). From your example, how would you tell from state published=0 whether the content needs to be approved or images need to be added? Those are two different states. Naming them explicitly makes the handling much more intuitive.

@nibra
I gave the simplest example. Knowing everything can be much more difficult

In the example, I cited the publication of the article step by step.
That is, if you do not have the rights can edit state you can not do

Step 3: Publishing 'bypassing Step 1&Step 2`

Naming them explicitly makes the handling much more intuitive.

Of course Naming is also needed, so that the employee knew what step is now.

P.S It seems to me to use the word state not very correctly because the column itself in the database is so called. And we get confusion when someone writes New state

@nibra

Creating and releasing workflow only for publish / unpublish / trash / archive is in my opinion highly undesirable. Because for many people this will only be a complication of the already established for the years of the system.

Or to do more from the beginning. Or not at all.

In addition, as I wrote many times before, the current workflow can not be integrated with the state of orders in shop components and com_users, and doing workflow only for com_content and com_contact is not advisable.

Creating and releasing workflow only for publish / unpublish / trash / archive is in my opinion highly undesirable. Because for many people this will only be a complication of the already established for the years of the system.

Since that would be a predefined default workflow, exactly nothing would change for the admin/manager. Nobody will be forced to add a workflow.

the current workflow can not be integrated with the state of orders in shop components and com_users, and doing workflow only for com_content and com_contact is not advisable.

That's exactly why we need a generic workflow solution. This PR (I'm talking about the concept and data structure; the implementation itself needs improvements) solves that.

In the example, I cited the publication of the article step by step.
That is, if you do not have the rights can edit state you can not do

Still missing an answer on how to distinguish step 1 and step 2.

It seems to me to use the word state not very correctly because the column itself in the database is so called. And we get confusion when someone writes New state

I guess that most of the confusion comes from that fact. Workflow provides a State Machine, so it deals with states and transitions. It does not matter, if the column is called state or published or featured in the current implementation.

@nibra

Still missing tha answer on how to distinguish step 1 and step 2.
Naming. The step display can be left as in the current PR but with improvements

nothing would change for the admin/manager.

Much to change. People can give a negative assessment to any improvement. The output can be something like this

Why did you spend time on Workflow, which only complicated the process, when there is a lot of everything you need to do.

I know a lot of these people. And for some of them, this may be the reason to refuse cms

All of this discussion just reiterates my initial point. This is not a workflow system or state machine in the way those systems are recognized or used elsewhere. This is a content publishing state management system. You are tying the internals of it very tightly to the current published/unpublished/trashed/archived publishing states we have in core today. It's this "conditions" thing that turns the generic workflow system into a very specific system that only supports content publishing.

When I think of what a state machine or a workflow system would define, I think of the workflow for processing a payment in an ecommerce platform or the specification for information reviews in the ongoing privacy tools work. Neither of those definitions are compatible with what is written here, which is extremely targeted at essentially what is stored in the state column of #__content. When I think of a state machine or workflow system, I don't think of the bulk of the Joomla ecosystem, which defines a rigid workflow that is not extensible or flexible in the way a proper state machine or workflow should be (the fact you have to add this "conditions" thing is your way of getting around the fact that core does not have a CCK type data model or a way to modify MVC layer attributes to introduce complex logic related to the state machine; you have to "dumb down" the system to meet the existing criteria of state being one of three or four values).

@mbabker

When I think of what a state machine or a workflow system would define, I think of the workflow for processing a payment in an ecommerce platform or the specification for information reviews

Given the privacy policy and other things, do not forget about com_users, and with its current database structure it can not be integrated with Workflow which is offered in this PR.

On large portals where content is added by ordinary users, com_content may not be used. Moreover, it is most often not used. But com_users in joomla are always used. And the workflow for him is much more important.

Or can just create a workflow only for com_content. Then you can change models and do everything need without fear of damaging other components in the future

At the current stage, we should just concentrate on the concept and data model. The implementation has a lot of things which I'm not happy with.

Looking from that perspective, the workflows that @mbabker pointed to are absolutely possible with this approach. The conditions in this PR were introduced just to keep existing data working, and should not be needed in a final version.

They don't keep things working.

(Unsubscribed)

Thank you @nibra for clearing things up. Indeed that extension is - as stated in the title from the beginning - at the current status a publishing workflow, implemented into com_content. Nothing less and nothing more. The concept behind can be used for the workflows Michael asked for and they can be linked to plugins. Of course it can be implemented for activating users in com_users etc. etc. Just someone has to implement it, using the existing helper (later library) class. It's implemented as a horizontal extension like categories.

And as Brian mentioned, we absolutely should not break the update from Joomla 3 => Joomla 4, otherwise Joomla is dead...

I don't see the advantage from your proposal @Septdir on an end user view it looks really complicated and you can also use this concept with the current one...

@nibra

Looking from that perspective, the workflows that @mbabker pointed to are absolutely possible with this approach.

Give an example. Given that the status of the order uses much more state than 0\1\-2

This is the biggest problem. And it shows that the implementation proposed in this PR in the root is not true.

There should be no imputations to the specific database structure of the database. There should be no bothers with a co-specific model.

This is the biggest problem. And it shows that the implementation proposed in this PR in the root is not true.

There should be no imputations to the specific database structure of the database. There should be no bothers with a co-specific model.

I'll try to draw. (I'm not a very good artist)

The future integration of WorkFlow, proposed in this PR with other components, looks something like this

Personally, I also want to see something like this

I would like the workflow capabilities not to be limited to one component (moreover, one column of one database) but allowed to corrupt actions that change the state and in other related components.

Examples especially associated with com_users can be an inordinate set

@bembelimen

I don't see the advantage from your proposal @Septdir on an end user view it looks really complicated and you can also use this concept with the current one...

Ok give an example of how I can make an example from this comment

• Name: Spamer
• Show in: com_users
• Actions:
  [com_users] Block user
  [com_content] Change state (unpublish where created_by = user_id)
  [com_content] Change access (Super users where created_by = user_id)
  [com_content] Change category (Spam items where created_by = user_id)
  #20244 (comment)

This simple action is necessary on any site where ordinary users can add articles to com_content and for some reason premoderation is impossible

At the moment, such operations take quite a lot of time.
In addition, you still have to take notes of someone you blocked as spamer

In short you use the Joomla! way: your plugin is listening to the transition event and is executing the different actions.

Of course you need a mapping in your plugin, because the states are abstract and not hard coded.

You only think in one direction. Namely, the publication of the article step by step.

And this need not so often. And this allows you to do the current version of joomla + the simplest CRM

Set can.edit.state only to Super Users and when all checks are completed, create a task for it. After notification, he will make the article published.

@bembelimen

In short you use the Joomla! way: your plugin is listening to the transition event and is executing the different actions.

Yes something like that.

More then a similar solution can be used for other tasks.

I have a similar component. For example, my friend uses to automatically update (via cron) uikit on his site, I personally still use it to clean up old files. I also plan to make a newsletter for users who have not visited for a long time.

Just initially, I did not come up with the idea that you can use it as a workflow. But now I have an approximate idea of ​​how to do this.

The main problem is lack of time and desire to do it right now.
Well, minor difficulties in the introduction of the absence of an event, to change the request to the database through the plugin, for filtering in the control panel

If the component is only designed to support com_content, then put it in com_content versus trying to make a horizontal and generic solution.

The fact you are removing archived state in com_content demonstrates a critical flaw, components can't add publishing states to the workflow.

@Septdir

Give an example. Given that the status of the order uses much more state than 0\1-2

Since you can define states, you can define as many as you need and give them understandable names. Forget about those magic numbers 0, 1 and -2. These numbers will be replaced by the states' id (if no mapping table is used). With the definition of transitions and the associated permissions you can control who can change a given state.

I fully agree that the workflow extension should integrate seemlessly like in your second drawing. To be able to do that, we need a well defined API (in case a component wants to address workflow stuff directly, likely needed for easy transition of existing components) and events to attach actions to certain state changes. That is what we need to discuss in depth.

Set can.edit.state only to Super Users and when all checks are completed, create a task for it. After notification, he will make the article published.

That's an awkward workaround, not a solution. BTW: Notification should be a separate subsystem reacting on events.

@nibra

Since you can define states, you can define as many as you need and give them understandable names. Forget about those magic numbers 0, 1 and -2. These numbers will be replaced by the states' id (if no mapping table is used). With the definition of transitions and the associated permissions you can control who can change a given state.

I can not forget about the numbers 0/1 / -2 because they are in the table #__content
And it is they who influence and will always influence publishind.

If you replace them with something else. As suggested in this PR, we will get an extra load and the inability to disable workflow.

Do not touch databases, models. Otherwise, disabling this component, as well as future migration from 3.x will be extremely problematic and can cause non-removable post-drives.

That's an awkward workaround, not a solution. BTW: Notification should be a separate subsystem reacting on events.

Turn this much more convenient than the proposed version of Workflow, even considering its future development.

Because I change state in one click. In addition, there are records of who and what did and of course notifications. Specific group of users.

P.S @nibra You have already tested this PR? On tried on it to moderate at least 10 material?

I can say that even if I improved the proposed option. Simply moderation of content with such workflow takes much more time. Than without it. Even if you do this step by step with crm

@Septdir

If you replace them with something else. As suggested in this PR, we will get an extra load ...

Not necessarily. Depends on the implementation (which I tried to say should be treated as non-existent for the moment).

... and the inability to disable workflow.

You cannot disable the current implementation of the publishing workflow, because it is hard wired all over the code base. You cannot extend it to cater for additional (fx. review) states. It is completely different from the (technically) same thing with other states in fx. a shop component.

Do not touch databases, models.

There are to possible approaches (and maybe a mix of those two):

1. Store the state (id) with the item.
2. Having a map (key-value store) of items (type:id) and their state (id).

The final solution might be a separate map and a state column in the DB table like now, filled with the appropriate value as a simplified Perspective on the real state.

Because I change state in one click.

That will in no way change.

In addition, there are records of who and what did and of course notifications. Specific group of users.

That's something that should be provided by plugins reacting on the StateChange events. That functionality does not belong to the workflow extension.

Simply moderation of content with such workflow takes much more time. Than without it.

Workflow !== Content Moderation. The latter needs a sophisticated workflow and a working versioning system (which we haven't got, since our versioning feature isn't able to manage drafts of changes to published articles).

@nibra

Workflow !== Content Moderation. The latter needs a sophisticated workflow and a working versioning system (which we haven't got, since our versioning feature isn't able to manage drafts of changes to published articles).

This workflow (in this PR) in only content moderation. There's nothing more he can not do.

And if the workflow will consist only in mapping the new state, then with this and com_tags to cope.

Workflow is often part of automation. The principle simply pressed the button externally changed the state after the fact, 5-10 values can be changed.

This PR is built on the principle of changing Publishing. This idea lies at its basis. What is displayed in the title New Publishing Workflow

And as already mentioned here repeatedly, this concept is not applicable to anything except com_content and similar components

If you abandon the current concept, and start everything from the very beginning, namely with planning and discussion, it makes sense to create a separate repository. And to discuss everything there.

My two workflow visions described above ( #20244 (comment) ). As it seems to me @bembelimen understood what he meant, and maybe even could provide an approximate implementation

@mbabker

The fact you are removing archived state in com_content demonstrates a critical flaw, components can't add publishing states to the workflow.

As Niels stated you can add unlimited publishing states to the workflow, the condition have only one task: to determinate if an item is visible/active/allows to do something (1) or not (0) so you see anything other conditions? Archived => visible => 1, if you want to display only the archived ones you filter directly by this state.

After speaking with @brianteeman and @wilsonge I'm closing this PR, improve some code and will reopen it.

Thank you for your contribution.

This is a complete nightmare on Beta7 - I have no idea how to simply write an article and have its status set to published.
It was so natural in J3 - there was a status dropdown that you set to published - bingo!. Or in the article list you clicked the red x in the status column and it was published, or you checked a number of unpublished artyicles in the list and clicked the publish button - Bingo!

Now the only thing I can find is to check the article in the list and use the actions dropdown and select Publish - and I get this message
"You're not allowed to change the publishing state of this item. Please use a workflow transition."

WTF does that mean? The whole workflow thing needs to be turned off by default and enabled for those who actually want to use it.

Write and publish - that's my workflow. J4 has become a nightmare of complexity - I hope the release is postponed forever until it at least works in a familiar way.
I am spitting mad at the time I have wasted trying to do the most basic thing.

Rant over, but this does need a serious rethink.

@rogercreagh Go to com_content options then integration tab and disable workflow. Nobody forced you to use this if you don't have a valid use case for it...

WTF does that mean? The whole workflow thing needs to be turned off by default and enabled for those who actually want to use it.

It is.

It is.

Not on my beta7 updated from beta6 updated from beta5 as installed it isn't.
I had added a couple of extensions, but nothing unusual, for testing.
It was only today that I got around to seeing how the article component worked and I certainly hadn't changed any of its options.
Workflow was on by default and (as you can probably guess from my post) caused me a certain amount of difficulty doing what seemed the simplest thing. I found this old post by searching for a solution.
Does an issue need to be raised to check that it is off by default? Mega confusion if it isn't :-(
Further searching told me that it could be turned off under options-content-integration - where it is right at the bottom of the page. (and thanks @dgrammatiko as well for pointing it out here - it wasn't easy to find and perhaps needs signposting)
This seems to be a very illogical place for it - integration used to be about rss and routing - integration with other things. Workflow isn't really integration with anything else - its a fundamental (anti)feature of the article system, and if it is on by default, or can get switched on by accident, then the switch needs to be more prominent.
Once it is off can you confirm it should be off for the whole site - including any existing articles - and remain off until it is manually switched on again.

On a clean install it is not enabled and never has been.

The sample data does however use the workflows as an example of what it is and how to use it.

(not commenting on the workflow functionality)

@brianteeman Ahha, that'll be it.
Given that people like me who are considering the implications of migrating from J3 are likely to start with a test site and install the sample data it might be a good idea to turn it off to start with in the sample data and include instructions to turn it on in one of the sample posts if wanted. Otherwise it risks giving a negative impression of J4 to people who have been using and tinkering with it since J1.5 (I think I even had Mambo briefly).
Make migration as easy and seamless as possible is essential or tempt people to switch to other platforms.

Please write that as a new issue. (not many people see closed issues like this).

I think a good option would be to have two sets of sample data. With/Without workflows.

here you go
#32387