Do we actually need stages now. surely the transitions is enough. It will simplify everything and resolve several of the identified issues

Do we actually need stages now. surely the transitions is enough. It will simplify everything and resolve several of the identified issues

The stage is a "label" now, we need it for 2 things,

1. which transition can be executed
2. Show the user on which position the article is in the workflow.

We also thought about removing it but didn't find a better solution

On a standard workflow ie the same as J3 and as available out of the box with j4 and this v3 workflow the label doesnt do either of those two things. Or am I missing something.

On a standard workflow ie the same as J3 and as available out of the box with j4 and this v3 workflow the label doesnt do either of those two things. Or am I missing something.

Yes that's true mostly because it's a mimic of J3. This workflow is not a real workflow because you can do any transition from any stage.
If you really use this feature you wouldn't do this.

A example with the default plugins (publishing, featured, notification)

4 Stages:

1. New article
2. Ready for proofread
3. Ready publishing
4. Live on site

Then you could have 4 simple transitions with access levels based on the user

1. Step
   Stage: New articles
   Execute Transition: Notify proofreader
   Plugin: Notification sends a message to proofreader
   New Stage: Ready for proofread

2. Step
   Stage: Ready for proofread
   Execute Transition: Notify supervisor
   Plugin: Notification sends a message to supervisor for approval
   New Stage: Ready for publishing

3. Step (Variant A)
   Stage: Ready for publishing
   Execute Transition: Go Live
   Plugin: publishing (Set state to published)
   New Stage: Live on site

4. Step (Variant B)
   Stage: Ready for publishing
   Execute Transition: Go Live and Feature
   Plugin: publishing (Set state to published), featured (Set state to featured)
   New Stage: Live on site

5. Step
   Stage: Live on site
   Execute Transition: Unfeature
   Plugin: featured (Set state to unfeatured)
   New Stage: Live on site

That could be a simple version, you need some extra transitions for trash and unpublish and so but the basic flow to publish a article could be like this.
And in this case we need the Stage so the user knows what he or she should do now.

you can do the exact same with transitions cant you

No because it would be much more complex looking at 3. you can execute 2 different transitions to get to stage "Live on Site". If you only use transitions your article would have the "Stage/transition" "Go Live" or "Go Live and Feature" based on this you need 2 new transitions for step 4 (unfeature).

So you duplicate all transitions after step 3. Also you would only see the last transition what you have executed and not what's current "state" or "next step".

Guess we are just going to have to agree to disagree here about my method to achieve the same thing being more complex. At the end of the day for a single admin site there is no need for this complexity and resulting poor ux at all.

As workflowV3 can be disabled perhaps it would make sense that

1. it is disabled by default
2. it is renamed Advanced Workflows
3. the sample/defaults matched an example like your above and not trying to replicate the disabled behaviour. If I recall correctly they only do that now because wfv2 could not be disabled

So if you need a custom workflow you can and if you dont need it you dont have to have it. Trying to satisfy two masters is what is breaking the ui/ux

I partly agree with you.

1. That's not my opinion but maybe an option
2. We only have on workflow so if we have "Advanced" there should be a "Simple" too ;-)
3. Yes that's true, that's also the reason why we have a "Publish & Feature" transition for demonstrating how it should work.
4. And yes it's a tool which likely not be used by sites having only one author.

So they only thing we disagree on is if it is enabled or disabled by default ?

Think so, yes but that's not a real problem I think ;-)

So they only thing we disagree on is if it is enabled or disabled by default ?

I would suggest a hybrid way:

• if there is a migration from Joomla! 3, the workflow is disabled by default and we deliver a very basic default workflow (in fact only workflow + 1 stage without transitions, because if people activating it now, they need anyways a custom workflow, they have to define)
• if there is a new installation, the workflow is enabled by default and we deliver an enhanced workflow (compared to the current version, a "best practise").

I am not convinced about it being enabled by default on any install. I see this as an enhancement for power users and larger sites. Smaller sites and sites with only one admin would not benefit from this and it is actually harder for them

I am not convinced about it being enabled by default on any install. I see this as an enhancement for power users and larger sites. Smaller sites and sites with only one admin would not benefit from this and it is actually harder for them

I see your point, but I disagree with "only one admin would not benefit from this". The power of the workflow is not only to give different user permissions to change something at stage X but not on stage Y but to give guidance and implement repeating flows. So if you have e.g. a blog and do always the same like:

• write text
• add image
• proofread text
• move to category x
• publish

You set up a workflow like this to make sure to be Poka Yoke.

If I am the only person on the site I am the workflow - I dont need software to control me and this would just make it slower for me

I am also in favor of setting workflow to default J3.
Now, what happens if one switches after some time from J3 behavior to workflows, and also the other way?

If I am the only person on the site I am the workflow - I dont need software to control me and this would just make it slower for me

It depends, for you, you need no software and that's ok, but I have several customer, where I gave them tutorials and documentation, how to create a new blog article, step by step. And exactly this can be covered by the workflow, independent how many user are in the system.

Now, what happens if one switches after some time from J3 behavior to workflows, and also the other way?

Nothing, it just continue working.

Please dont misunderstand me. This workflows v3 is great - especially with the notifications - but I just dont agree that it is suitable for all users (as described) and as they are the majority of the userbase then it must be something that you enhance your site with if needed and not something enabled by default. Advanced users are very capable of enabling something. Less advanced users are not - just look at how many users never change from using protostar or still have index.php in their urls. Workflows is too complex and not needed for them. You can still enable it for your clients ;)

Please disable by default. If/when there is time/desire to learn/use workflow, then it can be enabled, but it should not be forced upon.

Errors installing sample data.

Blog Sample Data:

There is an error in a sample data plugin. Response is invalid.

Testing Sample Data:

Step 4 Failed: You're not allowed to change the featured state of this item. Please use a workflow transition.

@bembelimen One test you haven't mentioned, and I think it's even the most important one: Update a 3.10 latest nightly or current 3.10-dev branch to J4+this PR by using the update package built for this PR. This package can be found via the link "Downloads" in the required checks section at the bottom (if necessary click the "Show all checks" to show that). At the same place is also a link to a custom update URL (XML file), which can be used with the Live Update of the Joomla Update Component, this is the most comfortable way.

Do such an update and check if things continue to work.

Should Edit Workflows be in its own fieldset and not be combined with Custom Fields?

Should Edit Workflows be in its own fieldset and not be combined with Custom Fields?

Where is this? I moved config options to it's fieldset... Maybe I missed them

should I put the outstanding issues from my workflow doc in the public issue now
all the serious ones are the ones that are left

The stage button is grey. something that is greyed out usually indicates that it is disabled

It is not clear that this is the stage and the list of available transitions. The column heading only says "Stage" for example

There is no way to click away from the opened list to close it. I am guessing there needs to be some js for this

// eventListener to select item
on click inside the list
select item and close the list

// eventListener to close the div
on click outside the list
close the list

Clicking on a stage to change a transition doesn't seem logical to me. Also note that on the article edit page the same information is labelled as a transition

Regression & Accessibility on status/featured button

We have lost all the information that you would normally see eg "pending but published" etc The data is still present but it is attached to a button which has been disabled so the information is not displayed visually or in the a11y tree.

The basic information eg Published/unpublished is also not present in the a11y tree so no way to know if the article is published or featured

@HLeithner Under Global Configuration > Articles > Integration tab

Article Edit Status

Really weird markup with lots of extra spans etc

Article edit status accessibility

There is no way to know the status of an article as it is not exposed in the accessibility tree

Transitions List

It is impossible to see what the status of the item will be after a transition as they now all say Basic Stage. Realistically all that list displays is the name of the transition and that the current stage is “Basic Stage” and the target stage is also “Basic Stage”
The label of the transition is just a label it doesn't explain the status

Security/ACL

There is no acl for workflows.

There is a permission in com_content for executing transitions which conflicts with edit own and edit state.

There is no way to restrict who can change transitions and status. Even a manager who has been prevented from executing a transition is able to go to workflows and change everything

@HLeithner Under Global Configuration > Articles > Integration tab

Sorry I can't replicate this, for me it's in it's own fileset with the caption "Workflow":

Please disable by default. If/when there is time/desire to learn/use workflow, then it can be enabled, but it should not be forced upon.

Errors installing sample data.

Blog Sample Data:

There is an error in a sample data plugin. Response is invalid.

Testing Sample Data:

Step 4 Failed: You're not allowed to change the featured state of this item. Please use a workflow transition.

@Quy I fixed this.

@bembelimen @HLeithner There is a failure in drone in the system tests for MySQL at the test labelled with I publish article "Test Article". I think it could be related to this PR. Could you check?

All articles installed with Testing Sample Data are unpublished.

That incredible amount of work, guys. Good job! ?

Sample data and drone are the result of turning off workflows by default. should be a reasonably easy fix.

Sample data are fixed, could s.o. please test, if they work as expected?

@bembelimen Multilingual sample data is ok, but articles of blog sample data and testing sample data are still unpublished after installing the sample data.

UPDATE: I've tested after a new installation of 4.0-dev with workflows disabled in com_content options.

If workflow is enabled in com_content options, the icons of the articles in the list views can't be used to publish/unpublish or feature/unfeature. Is that expected behavior?

If workflow is enabled in com_content options, the icons of the articles in the list views can't be used to publish/unpublish or feature/unfeature. Is that expected behavior?

Yes because it's managed with a workflow plugin

So performing a transition for an article works only with the actions button in the list view and with the transitions drop down in the edit view? I would understand that because there might be more than one possible transition .. I just have to learn all that it seems. Maybe I'll know more tomorrow night ;-)

So performing a transition for an article works only with the actions button in the list view and with the transitions drop down in the edit view? I would understand that because there might be more than one possible transition .. I just have to learn all that it seems. Maybe I'll know more tomorrow night ;-)

exactly as long as a plugin is active that provides this functionality, if you disable the featured plugin you can use the feature button again.

Remove Stage ascending/Stage descending from Sort Table By: dropdown when workflows is disabled.

It seems there is some language string missing or wrong for the stage filter drop down:

@bembelimen Multilingual sample data is ok, but articles of blog sample data and testing sample data are still unpublished after installing the sample data.

Thanks

@bembelimen After your last change, the filter is translated, and installing all kinds of sample data works with our without workflow enabled, and sample data articles are published.

@bembelimen It seems our system tests need a fix, too. Currently mysql system test fails here:

1) ContentListCest: Test that it is possible to create a new articles using "new" toolbar button.
Test  tests/Codeception/acceptance/administrator/components/com_content/ContentListCest.php:ArticleCRUD
Step  Click toolbar button "transition","2"
Fail  Link or Button or CSS or XPath element with '.button-transition.transition-2' was not found.

It seems the tests still assume that workflows are enabled after a new installation, which was not the case in my test a few minutes ago.

Remove Stage ascending/Stage descending from Sort Table By: dropdown when workflows is disabled.

781fab1

Editing an article on the frontend with workflows disabled.

Editing an article on the frontend with workflows disabled.

That is a template problem, the colors are wrong

Current Stage and Target Stage options not in Sort Table By dropdown under Transitions.

Is it ok for Stage ascending/Stage descending to be at the bottom of the list instead at the top where they would normally be?

Edit a stage. Is it correct with the Name field?

Thankyou @bembelimen , @chmst and @HLeithner for your hard work!

Thank you @wilsonge

Hi everyone,

Firstly, can I please thank everyone for their really hard work getting this together. My organisation wants to upgrade to Joomla 4 as soon as reasonably possible primarily for this feature. In our previous CMS (Liferay), we had a workflow functionality of sorts. We moved to Joomla 3 late last year and have so far got on with it very well, although we do miss the workflows.

I've just installed Joomla 4 Beta 1 on a test node so I can have a sneak peek at how this works.

One question though - and I hope that I'm writing this in the correct place.

All of the workflow functionality implemented thus far seems to work great for new articles. My question, however, is whether there is any functionality for moderating the edits of existing articles? Our approval team wants to be able to moderate changes to articles as well as new articles. In our old CMS, if an article was changed but a standard author, the last approved version remained published while the new version was sent of for approval. If it was approved, the latest version was published. If it was denied, the old version would remain published until a newer version was approved.

Do the new workflow states/transitions in Joomla 4 support this functionality?

Sorry to ask a question in this manner - I'm trying to understand what is likely to be possible in Joomla 4 and beyond.

Thanks in advance.

P.S. if this should be posted somewhere else, please let me know.

@bembelimen Could you check the above questions? What is the best place to ask these questions?

Hello @geekonthepc thank you for showing interested in the new workflow.

I think the best place is to ask in Glip. And feel free to contact me there for a deeper discussion.

But as I'm here, I try to answer your question.

In the core state a staging solution is not included, but there are plans to do it in coming releases.

So far the negative answer, the positive answer is: if you're capital to write your own plugin, you can write a workflow plugin to build this functionality. The idea could be, that you write a transition add-on which uses the versioning of Joomla for creating drafts. So saving a new version but reset the current version to the old one.
Does that help?

Hi @bembelimen

Thanks so much for taking the time to respond.

That's really helpful - thanks. The fact that staging of some sort has been discussed for a potential future release is certainly encouraging - as you say in the meantime a custom plugin could be the way forward to bolt on that functionality.

It's certainly good to know the current state of play so we can determine which route to take.

Many thanks

@geekonthepc If you plan to create or order a custom plugin, you might want to consider if you can fund a developer to do that as a core contribution. I myself have done this for the Smart Search component. A customer of mine needed basically that search functionality and with their support, I was able to refactor com_finder not just for them, but for everyone. Such a staging feature could be another good case for such a funding.

In \administrator\components\com_workflow\forms\filter_workflows.xml, the following:

	<fieldset name="group">
		<field
			name="extension"
			type="workflowcontexts"
			filtermode="selector"
			onchange="this.form.submit();"
		/>
	</fieldset>

generates:

		<div class="js-stools-field-selector">
	<div class="sr-only">
		<label id="extension-lbl" for="extension">
	extension</label>
	</div>
	<input
	type="hidden"
	name="extension"
	id="extension"
	value="com_content.article"
	 onchange="this.form.submit();">
</div>

Resulting a hidden field causing extra padding:

Is the code required here?