unable to test due to 500 error

Looks like a merge bug? That string shouldn't exist in this branch (because this hasn't been synced since last night and JM only introduced that string with ea4064a today). Either way I just merged 4.0-dev into this PR again so that should be fixed?

I don't get this String either.

Don't we want lang strings, xml and params to use the wording stages rather than states?

I.e.
instead of
PLG_CONTENT_JOOMLA_FIELD_CHECK_STATES_WORKFLOW_LABEL
use
PLG_CONTENT_JOOMLA_FIELD_CHECK_STAGES_WORKFLOW_LABEL
(same for DESC)

and for
if (!$this->params->def('check_states_workflow', 1))
rather
if (!$this->params->def('check_stages_workflow', 1))

therefore instead of
name="check_states_workflow"
rather
name="check_stages_workflow"

??

I indeed can't delete a stage, but I can delete a condition transition.
Is that expected?

Please see #21571

Resolved conflicts from that one JM

Remains eventual modification for the field name

if (!$this->params->def('check_states_workflow', 1))
rather
if (!$this->params->def('check_stages_workflow', 1))

therefore instead of
name="check_states_workflow"
rather
name="check_stages_workflow"

@bembelimen ?

That param needs to be removed to use the component parameter anyhow as per my comment

Apply PR by Patchtester got The file marked for modification does not exist: libraries/src/Workflow/WorkflowServiceTrait.php

@franz-wohlkoenig This file also was introduced by #21585

@wojsmol means not testable in my Environment.

@franz-wohlkoenig This works on CA but requires manual installation of nightly build zip. This bug should be reported to CA.

the Bug is that Nightly Build used by CA isn't the Nightly Build at https://developer.joomla.org/nightly-builds.html?

@franz-wohlkoenig I don't know exactly where bug is occurring but as you can see manual install on CA using zip from https://developer.joomla.org/nightly-builds.html is not equal to creating new site on https://launch.joomla.org/.

done: joomla/joomla-websites#1207

I have tested this item ? unsuccessfully on 85223e5

Installed sample data
Changed an article to "archive"
Trashed the stage called "archive"
--- this has no impact on the article even though it is trashed (similar to #21752
Empty the trash - expected behaviour is to get a warning about it being used

Actual behaviour is

Error 0: 0 You can't delete the default item.

Hello,

is it the "default" stage? Because this will be checked before the number is counted.

No

The problem is, that the sample data are not migrated, I guess.

If not done in this PR, it has to go further imho: whether there are or not articles assigned to the default Joomla workflow with its stages and transitions, it should NEVER be modified/trashed/deleted/whatever.

Why? There is imho no reason to add this restrictions. I think we should not fall back and have the old and the new system implemented but we should look for a modern/better solution... Some user just don't need the default workflow, so why bother them?

sorry to be so direct, but i'm afraid that few users really needs an advanced "workflow" or whatever you call what we have now in staging

Agree with @alikon

Some user just don't need the default workflow, so why bother them?

It would be much more bothering for users who don't need custom workflows.
People needing custom workflows would know what they do and not use the default one, in the same way as we are not forced to use custom fields and totally ignore that feature.

You can't compare fields with workflow as it is somwthing on top of an extension. While a workflow is part of the extension.

You can't compare fields with workflow as it is somwthing on top of an extension. While a workflow is part of the extension.

Alas... But in any case it does not make it necessary to allow deletion of the default workflow, used or not.

And to be able to choose a default state/stage (whatever you call it) when using save2copy with a specific parameter.

I have tested this item ? unsuccessfully on ff70dc6

What I've done:

• created workflow with transitions and stages
• created category and assign the new workflow
• created an article and assign to the category
• try to trash assigned workflow

expected result:
Can't trash the assigned workflow

actual result:
workflow can be trashed

I have tested this item ✅ successfully on ff70dc6

testing steps:

• created new custom workflow
• created new article
• used batch-function to assign the created workflow to the new created article
• tried to delete this workflow

-> Error message appeared: "This item is in use by the component."

Thanks @f-hamel for this find, could you test again.
@wilsonge I moved the methods, is that ok?

I'll do another review tomorrow. It's changed a lot since I first reviewed this

I have tested this item ✅ successfully on 10d8bc0

@bembelimen done ;-)

@lavipr can you please retest?

I have tested this item ✅ successfully on 10d8bc0

1. testing steps:
created new custom workflow
created new article
used batch-function to assign the created workflow to the new created article
tried to delete this workflow
-> Error message appeared: "This item is in use by the component."

2. testing steps:

• created new category and assigned new workflow (from test 1) to it
• created new article with new category
• tried to delete this workflow
  -> Error message appeared: "This item is in use by the component."

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21579.}

Ready to Commit after two successful tests. @bembelimen please resolve conflicting Files, thanks.

I resolved the conflict, but let's wait for @wilsonge review

Thanks :)