I have to reluctantly say I agree.
Another example of the issues:
Users may use various languages (even when the site is not multilang per se)
All these states, transitions, etc. are given titles in a specific language (by default in English) which can't be translated except if we enter a string constant as title and the code is modified to use JText:: everywhere these titles are displayed.
Which means that such new lang strings (or existing ones) have to be added for each installed language in overrides. (I know it is already the case for custom fields... grr).
The docs require a University degree to be fully understood.
To set up stuff, one needs a magnifier to read the State in the Lists.

All these states, transitions, etc. are given titles in a specific language (by default in English) which can't be translated except if we enter a string constant as title and the code is modified to use JText:: everywhere these titles are displayed.

They dont make sense in english either - so you're not alone

Apply this to a site and all your content disappears from the admin.

Are you sure you have tested this - this indeed got discussed in Cologne and a migration path was added:
https://github.com/joomla/joomla-cms/pull/20381/files#diff-ee69c2509d52da3aa9994355275b0ba5R124

More importantly as others have already discovered it just doesn't work

That's not the impression I got even when we sat down in Cologne. There were definitely UI optimisations to be made (but by far the highest priority item - any to any transitions did get made).

Anything that used the archive state is now completely broken as it is marked as published in the database

@bembelimen Is that just a typo? Shouldn't https://github.com/joomla/joomla-cms/pull/20381/files#diff-ee69c2509d52da3aa9994355275b0ba5R79 be -1 instead of +1?

The docs require a University degree to be fully understood.

It has docs which is more than what can be said for any feature merged for 3.x or 4.x in the last 2 years...... docs can be updated by anyone

All these states, transitions, etc. are given titles in a specific language (by default in English) which can't be translated except if we enter a string constant as title and the code is modified to use JText:: everywhere these titles are displayed.

This is good feedback. Do you have any suggestions?

Disable workflows in the options and all that happens is you lose the menu - it is still running

Also good feedback and obviously needs work

I would also add as a stage 2 that this clearly needs a more visual indicator and i would consider that important for a stable, however for the alpha state we're in I'd rather get this in so Benjamin can work on these things (with his team) and not spend his life merging in conflicts.

Hi all,

thanks for the feedback.

@bembelimen Is that just a typo? Shouldn't https://github.com/joomla/joomla-cms/pull/20381/files#diff-ee69c2509d52da3aa9994355275b0ba5R79 be -1 instead of +1?

No, archived has the published condition, so "1" is correct. They're just states now, nothing special anymore. (But people can still use them as before with the list-view/module)

All these states, transitions, etc. are given titles in a specific language (by default in English) which can't be translated except if we enter a string constant as title and the code is modified to use JText:: everywhere these titles are displayed.

Yep, that's the first solution atm. But I'm happy to discuss a better solution here. Are you fancy to have a chat the next days?

Disable workflows in the options and all that happens is you lose the menu - it is still running

Same as custom fields? It makes no sense to have 2 workflow approach for one thing...so of course it still uses the existing workflow if you disable the menu. The solution here would be to remove the option parameter, if this annoys you.

getting assurances that things would be changed I dont see that at all.

https://github.com/joomla/joomla-cms/pull/20381/commits

Apply this to a site and all your content disappears from the admin.

Are you sure you have tested this - this indeed got discussed in Cologne and a migration path was added:
https://github.com/joomla/joomla-cms/pull/20381/files#diff-ee69c2509d52da3aa9994355275b0ba5R124

Yes I am sure i installed with the test data and it was present in the front end but not the admin
Just did a clean install with no test data and then installed the sample data from the plugin and I get this

No, archived has the published condition, so "1" is correct. They're just states now, nothing special anymore. (But people can still use them as before with the list-view/module)

Not if their query was based on the value of the state field in the _content table

We discussed this at jab

This is good feedback. Do you have any suggestions?

alas, not any that would not require using existing constants and creating new ones.
Example of modified code using JText:: for the title (should be Text:: but this is a detail) in states template.

					<td>
										<?php if ($canEdit) : ?>
											<?php $editIcon = '<span class="fa fa-pencil-square mr-2" aria-hidden="true"></span>'; ?>
											<a href="<?php echo $edit; ?>" title="<?php echo JText::_('JACTION_EDIT'); ?> <?php echo $this->escape(addslashes(JText::_($item->title))); ?>">
												<?php echo $editIcon; ?><?php echo JText::_($item->title); ?>
											</a>
										<?php else: ?>
											<?php echo JText::_($item->title); ?>
										<?php endif; ?>
									</td>

and title would be in this specific case:

Did not really understand fully the docs explaining how to create a "Needs Review" or anything else and, honestly, given the complexity of the feature, I would not touch them.

BTW: should ship with magnifier ;)

Workflows List

• Search ordering ahould match table column ordering
• States column "Manage" - is a link not a meaningful term for the item - should simply be a button with the name
• States/Transitions Icons in column headers. These are completely meaningless - no idea why you have them - can only assume it is to try and save column header width
• Author Column - why?
• Ordering - why?

Edit Workflow

• WTF is the description field for - at most it should be a note field

Transitions

• Should be changed inline and not in a new view

Archived

• Broken

Notifications

• No way to see what items are yours to deal with such as email or dashboard

Thanks @brianteeman we'll go through your list and look what has to be changed.

I haven't looked at the code and I didn't test it, but till now I didn't read an argument to revert the pr. All the issues which are listed here can be fixed in new pr's. If the architecture would be wrong, then I'm pretty sure that @wilsonge would not have merged it. It was the right time for a merge as there is now enough time to finalize it.

Joomla V4 will take a long time until it is ready for a release. During this time it will be much easier to work and contribute when the feature is merged and more constructive feedback is given. In a few hours we have got here some good feedback. Negative feedback too - but new featurese are always accepted with reservation, this is normal.

sorry to disagree but the current status of this feature is a lot far imho from a decent status and
i've only looked at sql/db things, even in Alpha....

@chmst I gave the exact same feedback twice - first exactly one year ago and it was rejected. Again at Jab and it was mostly resolved. But no code has changed.

A workflow system without a notification system integrated with it is completely useless. That's not something a UX designer can resolve. Nor is it something anyone reviewing code for obvious errorss can resolve.

@laoneo

I haven't looked at the code and I didn't test it,

Please do and then you will understand

Joomla V4 will take a long time until it is ready for a release

It shouldn't do unless we have to sit and wait for this feature to be implemented. Sorry to say but after 2 years it is nowhere near ready. By merging it here the workflow team are passing the work onto everyone else who could be better used getting joomla 4 ready for release.

A workflow system without a notification system integrated with it is completely useless.

And I can only repeat, what I told you on both days: The notification functionality is already implemented, look into the Joomla!-Content plugin.

Adding such a big new feature is not an easy job. As we merged CustomFields it was also not ready, some people might remember.

The question for me here is: Is it realistic to make this feature useful before we reach RC state?

I am optimistic that this is possible.

I do not agree with reverting the PR, the "Workflow team" has just started to take off and we need help, I am sure all the issues mentioned in the discussion can be addressed and even the current ones can be improved by the experts, please show some positivity.

@rdeutz fields was an optional feature that did not effect every aspect of a website. Of course it can be made useful before we reach RC if we dont want to have an RC until 2025. Based on the lack of progress in the last year I see no possibility that this can be made usable.

@bembelimen and as I told you then - relying on email alone is wrong

@puneet0191 hard to show any positivity when it is so bad

Reverting != rejecting

Based on the lack of progress in the last year I see no possibility that this can be made usable.
This is maily because it was not merged - it was a pain to get it synchronised with the main branch.

weird concept: lack of progress cause not merged
should be not merged cause lack of progress

Personally I'd argue this sets bad precedent. I dare say we've been on a slippery slope the last couple of years with when features are merging to the main development branches for each release. Many of the "major" 4.0 features have merged before "ready", custom fields being another big one, some will argue this applies to routing as well. By that logic, my crew should have just direct PR'd the privacy tool suite work into the 3.9 branch and iterated as we went instead of having one feature complete pull request for feedback that is now sitting not getting said feedback, and the solution to that is to just merge it and hope the feedback and any issues that present themselves are raised and addressed before tagging a stable release.

It's one thing to merge something that is considered feature complete and usable and any follow on work is iterative improvement from that point. But by all accounts, the workflow system is anything but feature complete and usable and is now disrupting the bits and pieces of 4.0 that are actually working or looking the way they're intended to.

It is really hard to try and fix this code because the code comments are either all the same, so generic to be meaningless or completely wrong.

I understand it's not popular with everyone but I want to solve these problems not revert it out

I want to solve them too but it will be much much easier and less of a distraction o do it in its own public feature repo than messing up everything in core - its a massive distraction.

As each day goes on we discover more and more issues with this code. :(