Frontend Workflow decoupled from edit view. Available as in attached pics

[denvarel]

Is your feature request related to a problem? Please describe.

Having decoupled workflow feature just in backend is a big drawback. Most users do not need to go in backend in order to do trivial operations (like publishing). More than that: a preview of the article, right how it will look like if published, is preferable to a list view (as in backend is). Is a lot user-friendly to see in frontend the article that need an workflow action and do it, than in backend.

Describe the solution you'd like

As in attached picture: the frontend workflow should be available in the "tools" hover popup, entirely decoupled from editing view.

The workflow interface may open in popup as:

Additional context

[brianteeman]

spam - please delete and block servenomaster

[oms674]

hey, I would like to fix this issue can someone explain the project as i am new in here.

[denvarel]

hey, I would like to fix this issue can someone explain the project as i am new in here.

First is not an issue that need fixed, is an usability improvement.
In backend the workflow mechanism is decoupled from editing view though a dedicated button.
In frontend, the workflow is available through the article editing view. meaning that the workflow can be accessed only when you actually edit the article. Thing that implies editing rights, thing that is quite strange since once you are there you can do manually all the operations that the workflow does and the "workflow feature is redundant.
But if the workflow is outside the editing, in frontend, then a whole new world is opening: With proper rights an user may do short and very precise actions without having access to the other actions available in edit view.

For example, an user can add an image using an image workflow, and only that. He cannot change the content.
Or he can change the article status without being able to change the content and images.

[brianteeman]

Please note that this is a massive feature request and certainly not something that can be quickly or easily achieved.

[denvarel]

I don't fully understand the complexity since I'm not a coder. I'm more an solution integrator.

I still would like to emphases that the workflow feature in backend only, in the current implementation, is quite useless (PLEASE don't feel offended, I do know that it required a lot of work. But only that work alone is not making it good for something/usable. Is more like a beautiful spaghetti code that does nothing useful at the end).

Let me underline the user's point of view: I'm in charge of doing some Workflow steps. Does not matter which ones.

1. I log in in backend and I see a list of articles titles that need processed and some current "stages" associated. Nothing more, (beside the date, author and hits that are useless in article's user evaluation)
2. I do have to open an article in order to be able to take a user decision about next workflow's steps. I cannot do it blindly.
3. I open the article, I'm in editing view. :)

So what is the purpose of having the workflow feature if I'm ending anyway in editing view, in order to decide what to do? Just to have a marker with workflow's "Stage" next to the article's titles list? I cannot use that marker (even I can do that, technically) without checking the article's content itself, in order to decide (for example: to publish it) what to do.

A usable workflow functionality is to

1. See the entire article or article's draft, (ideally, as it look like if is published in frontend, with template's css)
2. Read it (check the pictures, something else),
3. Decide what to do with it
4. Taking an action: trigger a workflow next-step button.

And this is possible only in frontend. And only in article's view. Maybe in Category view with the content till readmore. Not in the editing view, and certainly not in a list of article's titles, as it is now in backend.

Is clear that without the steps 1 to 3 from above, the workflow feature is technically working, but who need it? It cannot be used because it means that is used with the eyes closed.

Become obvious that having a feature in frontend, with granular privileges for each stage, is a revolution in Joomla usability. Suddenly you can have a photo department that adds pictures without being able to alter the text, a redactional team that is able to proofread the articles and approve or not the publishing, even teams that are exclusively taking care of SEO, adding keywords, tags, page titles, without altering the content and so on. Workflow's transition actions should be independent from editing view. But able to do certain (if not all) functions from the editing view (publish, add pics, edit text, choose category, alter a specific custom field).

Look at the editing view as a collection of "transition actions". The workflow functionality should split that collection into small functional chunks, available separately from each other.

Even more! Building complex functionality as support tickets is possible with the extraordinary help of Joomla custom fields or with a third party component as RS form (that transforms a submited form in an article)

[denvarel]

@drmenzelit @Hackwar , I mentioned you both since both of you have added "New Feature" for this idea.
After almost 2 years since Joomla Workflow feature was presented there are no new functionalities added. The only addition to this is a image processing #30421 which is not working anyway.
The main issue with Joomla Workflow is that is not available in front-end. In back-end, any step of an custom workflow implies

• Either to choose to next Stage blindly (in Articles list, using Change Stage dropdown but seeing nothing but Article's title)
• Either to enter in article's editing window, thing that defeats the original purpose of having granular privileges for different roles in workflow.
  If a similar functionality as the Change Stage dropdown will be available in frontend then a limited publishing custom workflow may be possible since the whole article is visible, and the user with publishing rights can take a decision based on how entire article looks not only seeing it's title. But again, the functionality will be limited at changing Status and Featured flags of Joomla's articles. No editing/ proofreading possible, no image adding, no programming a expiry date, no custom fields, nothing. For any of those actions there is need for entering in Article's editing Form, action that defeats the purpose of having granular defined custom workflow stages.

I think that the present Joomla workflow idea will be dropped, as it is implemented now, because does not bring any functionality to Joomla. I see it more like a proof of concept than a usable thing.

An idea struck me looking at another successful entity of joomla: Custom Fields, organized in Field Groups (or Custom Field Category, there is a inconsistency of naming in Joomla 4.2):
What if the workflow's transition action is a Custom Field group that contains a collection of custom fields?
Boom: Joomla has already a nice collection of Custom Fields, third party custom fields are already developed by various developers, There are already modules and components and features (search) based on Custom Fields. All that is left is to use those already existing and working entities into the Workflow entity.
Instead of building new actions for the new (currently crippled) workflow feature we can use the already known, wide used and well established custom fields.

Still, there is need for a collection of System Custom Fields that will have to do the completion of Joomla's article's database fields:

• Article content
• Category
• Tags
• Note
• Version note
• Intro Image
• Full Article Image
• Start publishing
• Finish publising
• ...and so on...
  Those System Custom Fields can be added to any Custom Fields Groups and used in any workflow transitions, in any combination possible! And are quite easy to implement!

Instead of having the complex, illogical and User rights conflicting usage of the Article editing form to manage the workflow stages there should be a new built Workflow form that loads a Custom Field group for each transition.
And a separate system plugin that change the Edit Button link and loads the Workflow form instead of editing form in frontend. Publish it and, the workflows takes the front-end control instead of the edit form. No fuss with current category, categories, articles views.

[pmoscatelli]

This is a great idea. Like someone mentioned, it will probably require considerable effort.
maybe giving the admin the possibility to at least show current stage in the front end would be great. Much simpler, although not what was proposed here. maybe I'll suggest it in a new thread.

I wouldnt say the current workflow feature as it is implemented is useless. quite the contrary.
The workflow CAN do actions like publish or feature, but the stages themselves represent a state, that can be completely independent from the published/unpublished or featured/unfeatured. A have a workflow where I can promote an article to a different stage when tags assigned to it have been reviewed by a specific user.
I have another workflow for planification of certain jobs outside of joomla, with different stages: development, for approval, approved, and production. Nothing to do with the joomla article being published or unpublished.
All in all, I'm loving Workflow.