[4.0] Feature/New Publishing Workflow #20244

bembelimen · 2018-04-26T22:17:27Z

Hello everyone,

with the Google Summer of Code 2017 project, we implemented a new workflow extension in Joomla! 4, which replaces the current publish/unpublish/trashed/archived state. We want to implement a flexible and unlimited workflow which can be extended for other extensions, too.

Presentation at the JWC 2017: https://www.youtube.com/watch?v=5e-HECq44B0

Additional Information

https://docs.joomla.org/Publishing_Workflow
https://docs.joomla.org/GSOC_2017_Project_Ideas#Project_VI:_Publishing_Workflow_in_Joomla.21

Testing Instructions

Install the Joomla! 4.0 and go to the Article manager, there you'll find a new menu entry "Workflows", play with it around. You can also use the implemented default workflow.

Workflows will be assigned in the category parameters.

Needed help

As I mentioned before, this feature was a Google Summer of Code project. Sadly I'm the only person left and I can't solve everything in a short time, so I'm looking for help.

One big unsolved issue (beside some clean ups) is the migration path from Joomla! 3.x to Joomla! 4.x. Here I need help (perhaps @laoneo can give some tips)...

I would also like to see better Javascript, perhaps @dgrammatiko could you help me here?

And last but not least there is a lot of clean up to do. I would be very grateful for every PR, which improves the workflow code. Thank you in advance.

Images

Comments, tips, support would be very appreciated!

…blishing_workflow into archived-status # Conflicts: # administrator/modules/mod_menu/preset/enabled.php # installation/sql/mysql/joomla.sql

…blishing_workflow into archived-status

…rchived-status

…GSoC17_publishing_workflow into archived-status

…rchived-status

…le transitions to edit view of article

* fix getting state in front end menu-item and module * fixing featured list view with transitions and remove publish, unpublish, trash buttons * adding language terms for workflow

…GSoC17_publishing_workflow into front-side-bugs

Remove unneeded translation

Remove unneeded description

Resolve issue #97, Resolve issue #84, Resolve partly #95

# Conflicts: # media/system/js/core.min.js

Septdir · 2018-05-07T14:37:08Z

@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?

Septdir · 2018-05-07T14:39:15Z

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

nibra · 2018-05-07T15:05:15Z

@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):

Store the state (id) with the item.
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).

Septdir · 2018-05-07T15:26:02Z

@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

Validate before status change to trashed if no items are assigned

bembelimen · 2018-05-08T03:04:36Z

@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.

Fix minor html errors

Publishing workflow library

…g-workflow # Conflicts: # administrator/components/com_content/Helper/ContentHelper.php # administrator/components/com_content/View/Articles/HtmlView.php

…g-workflow

bembelimen · 2018-05-12T16:09:09Z

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

Thank you for your contribution.

rogercreagh · 2021-02-10T16:44:03Z

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.

dgrammatiko · 2021-02-10T16:49:45Z

@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...

brianteeman · 2021-02-10T17:42:45Z

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.

rogercreagh · 2021-02-10T18:06:37Z

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.

brianteeman · 2021-02-10T18:15:09Z

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)

rogercreagh · 2021-02-11T08:15:17Z

@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.

brianteeman · 2021-02-11T08:24:03Z

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.

rogercreagh · 2021-02-11T18:09:51Z

here you go
#32387

Jan Jaracz and others added 30 commits August 18, 2017 01:32

Improve ugly part

b1a5c80

Multi select states in com_content Archived Articles view

0a6bd5d

fixing front-end issue again (#77)

1ae6a60

Merge branch 'master' of https://github.com/joomla-projects/GSoC17_pu…

213110b

…blishing_workflow into archived-status # Conflicts: # administrator/modules/mod_menu/preset/enabled.php # installation/sql/mysql/joomla.sql

Merge branch 'master' of https://github.com/joomla-projects/GSoC17_pu…

6b7ea8c

…blishing_workflow into archived-status

Merge branch '4.0-dev' of https://github.com/joomla/joomla-cms into a…

39df0f6

…rchived-status

Merge branch 'archived-status' of https://github.com/joomla-projects/…

7549e82

…GSoC17_publishing_workflow into archived-status

Merge branch '4.0-dev' of https://github.com/joomla/joomla-cms into a…

e8ac00a

…rchived-status

Changes plugins, modules to com_workflow and adds select with availab…

10d8da0

…le transitions to edit view of article

Fix publishing fields in edit view

a171d64

Fix menu workflow item

3ddf4e2

Fix transition select field, Adds acl checking in that field

5bf746c

Fix plugin

21f5291

This trying to fix module issue with passing states

a5dee4c

Add states to archive model

3ea6fe4

Fix all bugs

0ce67f6

Fix code style

8ecbf76

Fix bug with workflows, Fix deletion issue

0895502

Fix featured list view (#83)

6a98f44

* fix getting state in front end menu-item and module * fixing featured list view with transitions and remove publish, unpublish, trash buttons * adding language terms for workflow

fix getting state in front end menu-item and module (#81)

4a74000

Adds minified version of core.js

b818382

Merge branch 'front-side-bugs' of https://github.com/joomla-projects/…

55936ac

…GSoC17_publishing_workflow into front-side-bugs

Update filter_workflows.xml (#87)

8ca5202

Remove unneeded translation

Update filter_transitions.xml (#92)

336e068

Remove unneeded description

Update filter_states.xml (#93)

dcda9a9

Remove unneeded description

Fixed: id of the select list mus be unique, Improve class

657462c

Resolve issue #97, Resolve issue #84, Resolve partly #95

e171ac9

Changes default view of com_workflow to visible

48c41a3

Merge pull request #101 from joomla-projects/issues

daeabf6

Resolve issue #97, Resolve issue #84, Resolve partly #95

Merge branch '4.0-dev' of github.com:joomla/joomla-cms into staging

5faca98

# Conflicts: # media/system/js/core.min.js

Validate before status deletion if no items are assigned

596750d

Validate before status change to trashed if no items are assigned

bembelimen and others added 14 commits May 8, 2018 13:54

Moved transition form field to the libraries folder

9b8c734

Moved transition form field to the libraries folder

b323d83

Implement Workflow library class with condition constants

e7b16ab

Fix minor html errors

Merge branch 'publishing-workflow' into publishing-workflow-library

2c677ef

Merge pull request #10 from bembelimen/publishing-workflow-library

b709c78

Publishing workflow library

Merge branch '4.0-dev' of github.com:joomla/joomla-cms into publishin…

2e65102

…g-workflow # Conflicts: # administrator/components/com_content/Helper/ContentHelper.php # administrator/components/com_content/View/Articles/HtmlView.php

Fix workflowHelper Submenu call

f0aa58e

Add Workflow constant to the frontpage

78a4ce7

Moves state select field to the library folder

d121f01

Fix some sniffer errors

5d838e0

Fix wrong parameter structure

1d4eb57

Merge branch '4.0-dev' of github.com:joomla/joomla-cms into publishin…

6402176

…g-workflow

Fix wrong input parameter

114c5dc

Fix transition filter in the form

5d91bac

bembelimen closed this May 12, 2018

Uh oh!

[4.0] Feature/New Publishing Workflow #20244

[4.0] Feature/New Publishing Workflow #20244

Uh oh!

Conversation

bembelimen commented Apr 26, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Additional Information

Testing Instructions

Needed help

Images

Uh oh!

Septdir commented May 7, 2018

Uh oh!

Septdir commented May 7, 2018

Uh oh!

nibra commented May 7, 2018

Uh oh!

Septdir commented May 7, 2018

Uh oh!

bembelimen commented May 8, 2018

Uh oh!

bembelimen commented May 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rogercreagh commented Feb 10, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dgrammatiko commented Feb 10, 2021

Uh oh!

brianteeman commented Feb 10, 2021

Uh oh!

rogercreagh commented Feb 10, 2021

Uh oh!

brianteeman commented Feb 10, 2021

Uh oh!

rogercreagh commented Feb 11, 2021

Uh oh!

brianteeman commented Feb 11, 2021

Uh oh!

rogercreagh commented Feb 11, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

bembelimen commented Apr 26, 2018 •

edited

Loading

bembelimen commented May 12, 2018 •

edited

Loading

rogercreagh commented Feb 10, 2021 •

edited

Loading