[#21553] - [4.0][Workflow] POC fixing multilingual sample data
- Closed
- 13 Oct 2018
- Medium
- Build: 4.0-dev
- # 21553
- Diff
- infograf768:4.0_workflow_multi_sampledata
User tests: Successful: Unsuccessful:
Pull Request for Issue #21548
Summary of Changes
Adapting multilingual sample data to workflow
Testing Instructions
Patch tester should be OK.
Just do as usual, i.e. install some languages (French, German, Persian) and click install in CPanel
Why is it a POC?
For the simple reason that the default workflow may have been changed or the "Joomla! Default" one in core modified (WHICH BTW should have as title a translatable language constant), thus state 2 could be anything instead of "Published".
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End Plugins |
| Labels |
Added:
J4 Issue
?
?
|
||
| Category | Front End Plugins | ⇒ | com_workflow Front End Plugins |
| Category | Front End Plugins com_workflow | ⇒ | Front End Plugins |
I have tested this item
Got on Blog (maybe Part of #21551):
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21553.
| Category | Front End Plugins | ⇒ | com_workflow Front End Plugins |
- evidently first check is workflows are Enabled...
There is NO option to disable/enable workflows. You have no choice - this workflows pr completely replaces the current working system.
That is why I am so insistent that the code is correct. The only reason that the current/previous states still exist in the com-content table is for b/c with extensions eg content-modules. Although that is not true either as it will only write published/unpublished/trashed into that table and will not write archived.
The option that you are thinking of works the same as the one for custom fields. ie it hides/shows the menu admin links. The logic being that once you have workflows setup then you don't need to see it again. Yes the language string for both needs to be improved.
If people spent the time to truly test this workflows stuff in a real world scenario they would see why it is not ready at all and will require fundamental changes before it can even be considered. The fact that it ignores the ACL is the most critical to me.
after applying this pr still issues
I had this too until I have deleted the autoload file and repeated the composer / npm stuff.
There is NO option to disable/enable workflows. You have no choice - this workflows pr completely replaces the current working system.
There is an option in the com_content options. But all it does is hiding the workflow menuitem. Unfortunately, it doesn't disable workflows itself as you said.
And this is a fundamental problem with workflows. Because most users will not need it at all and the chance to mess up something there is big. Fixing it once it is broken needs full understanding of the inner workings. It's not intuitive at all if you're not a developer.
We were told at jab that out of the box it would work the same as the status quo. Sadly that is clearly not the case at all especially with it ignoring the ACL
with it ignoring the ACL
I brings its own ACL in the workflow and the transitions, making the ACL in the component itself quite redundant. Good luck with finding why someone suddenly can't publish thought.
| Title |
|
||||||
| Category | Front End Plugins com_workflow | ⇒ | Front End Plugins |
is this PR waiting for a second Test or something else?
is this PR waiting for a second Test or something else?
Responsible for 4.0 development should decide.
I personally think we should wait a general solution to workflow.
For example: what happens if a workflow, including the default one, has been deleted?
Closing as another code has taken care of this.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-10-13 09:31:47 |
| Closed_By | ⇒ | infograf768 |
will test Today.