It may conflict the new J4 custom workflow feature in which only some users can publish / unpyblish contents

Not really, the version permission is at the moment linked to the edit-permission of the article itself. In the future perhaps we could move the permissions to the workflow stages, so you can setup article permissions based on the stage...

Hi
The problem is that now if someone is granted to edit permission he can go back to any version which may be conflicting with the fact than only some users can decide what's on line.

Giving the access to the version control to anyone allowed to edit can break the publishing policy

thanks

This is why I suggest to add a "version control access" permission in the com_content permissions tab

@pulsarinformatique as new Features goes in J4 is it your Interest as Feature Request for J4?

hello

yes, definitively !
thanks

cyril

@pulsarinformatique please append "[4.0] " at Start of Title.

I'm not sure if this permission makes sense. If you have already edit permission you could just put in the old texts without going over the version control, so where is the benefit of this permission?

Hi

Right now ANYONE can access the VERSION button . It may conflict the new J4 custom workflow feature in which only some users can publish / unpublish contents.

if some users can't publish or unpublish contents thanks to the new custom workflow system BUT can access the Version control it conflicts the workflow

thanks

cyril

Right now ANYONE can access the VERSION button

Yes I understand this but I don't see the problem here? If someone has edit rights, why shouldn't he/she/it access the version button?

Right now ANYONE can access the VERSION button .

Afaik, not anyone. Only those with edit permissions. And those by design.

Can you give a real world example of a scenario where you see the problem

Hi
This is simple : let's say we have a mygroup group whose members can't edit the contents, just read them. Since they have access to the VERSION button they can revert to an older version thus modifying the current content !

Therefore we whould add a "edit versions' permission in com_content so that only some given user groups could actually get access to the version control.

thanks

cyril

This is simple : let's say we have a mygroup group whose members can't edit the contents, just read them.

Is that even possible?

you take it the way you want: having the possibility to revert to a former version shouldn't be accessible to everyone. This should be controled.

If a user is able to edit the content directly then I still don't see the benefit/need to prevent them from accessing versions. Thats what I am really trying to understand

If you take my first post here you will read the issue comes with J4 new workflow. With this powerful new workflow system you now have cases in which you allow some users to edit a content BUT you don't want them to publish it!

If these users cand access the versions button they will automatically publish a former version !!!

This is why the new workflow system forces us to more precisely control the versioning access.

In J3, as you wrote, only people who could edit a content could access the version control. if such users were able to edit contents it was understandable that they could access the versions.

but now with J4 we have a much more customizable workflow system as I wrote. And this is a very good move which suits the needs of most of our customers who want precise workflows.

thanks

cyril

Ok, I think I understand the issue now. I have to check first, but I think the problem is on a deeper level:

1. The front-end still does not implement the workflow correctly in all places: #21702
2. I have to check if the version correctly handle the state (I guess not)

This is simple : let's say we have a mygroup group whose members can't edit the contents, just read them. Since they have access to the VERSION button they can revert to an older version thus modifying the current content !

If they can't edit the content, then they of course shouldn't have access to version. If that's currently the case (haven't tested), then that is a bug to be solved.
It doesn't need an additional permission, it just needs to properly check edit permissions.

Hi

any news on this question please ? As Bakual stated the version control button should not be available for users who don't have the publish permissions.

thanks

cyril

@pulsarinformatique I didn't write "publish" permission. I did write "edit" permission. That's not the same.

Hi

I believe the issue remains. Here is a scenery that illustrates the issue :

Let's say we have authors (can create, edit his own contents but can't change the status) and publishers (can edit and change the status)

let's say that if an author creates an article, this one is unpublished by default.

If a publisher edits the content, modifies it and publish it we surely don't wan't the author to be able to change the published content and revert to a previous one.

BUT as he can edit his own content, he can access the VERSIONS button and revert to any previous version.

So at the end the author modifies the validated and published content !

This is why in the first place I asked to add a 'version control persmission' in addition to 'edit his own' , 'edit ' or 'delete' permissions.

I believe we must be able to prevent an author to revert back to a previous unvliadated version.

Thanks

Cyril

So your issue is that he can unpublish his own content?
That he can edit it, is part of the "edit.own" permission. So he can of course also alter a validated article and put some completely different content up, be that an older one or a completely new one.
The only thing which changes is that it would unpublish (if it really does that). That could be prevented by checking the edit.state permission before applying changes to the state property, which actually sounds like a real bug if that is not already happening (never tested myself).

Hi
No, the problem is NOT ONLY that he can unpublish his own content.
As you understand, the problem is that the author can RUIN the whole purpose of the workflow!

The workflow is here (in this example) to give some group (the publishers) users the permission to correct and publish the content. Once the author can revert to a previous versions, the whole purpose of the workflow COLLAPSES since everything the publishers did is ignored!

This is why, as I understand you suggest, we should add some checkings before someone reverts to an older version :)

Thanks a lot

Cyril

So just remove the edit.own permission - doesnt that achieve exactly what you want

Hi Brian
not sure I understand what you mean
of course we don't want to remove the edit.own permission to the author: he CAN modify his content BEFORE some publishers approve it and publish it.

But that would be another issue and isn't related to versions. He can always edit the content after it was published, regardless of versions.
The solution is to remove edit.own if you don't trust the user. Instead of editing the article he then has to create a new one.

the workflow and the versions control have been designed separately which is the basis of the issue here.
As I explained many times above : once you give the full versions control to the author he can break the whole meaning of the workflow.

many be the solution is to find a way to BLOCK the access to the version control to some users once the content has reach some status. This is a notion that is missing now.
thanks

I'm sorry but this is not the reality of bigger sites with workflows.
this is not a question of TRUST only:)

once the organization (your customer) has defined some edition rules they have to be applied. you cannot just 'trust' the authors that they won't ruin everything the publishers did.
when a customer asks us to build a wokflow it has to be contraining

of course an author SHOULD be able to edit his own content in the early phases of the content. He needs to edit it several times before some other people check, complete, validate and publish it.

but once the content is published the author SHOULD NOT be able to modify the on line version!

Thanks for your understanding

This is nothing to do with the versions button. That's a red herring. Currently if you have permission to edit.own then you can change the content as @Bakual stated before #23537 (comment)
What you need is something that will allow edit.own but only when the state is not published?

Brian
yes, you CAN'T separate edit permissions from workflows.
yes, there are stages where the edit.own permission should not be allowed.

in a REAL workflow in REAL business projects no organization will acccept that someone who is just allowed to propose contents can CHANGE the contents once it's on line. Isn't that clear enough ?
thanks

How about letting the Publisher have rights to change the owner as a part of the publishing step, to secure your flow and process? (as a superuser can do today)
So when an Author (creator/owner) submit for publishing, then the Publisher change creator/owner to self, and add author in Created by alias. That would remove the issue as they don´t own the content and you would still be able to credit them by showing alias in front for Written by.

Hi
yes, this could be a possibility but we have to think it globally not just in this scenary but I guess your suggestion makes sense.

this could not only be linked to the change.status permission. Can we say that everytime someone change the status he becomes the owner ? I don't think so but we surely can ADD some attribute/option to the workflow stages:

When we define a STAGE in the workflow, we may have a toggle button that will make this stage change the owner of the content!

What do you think of that?

Anything that deals with permissions on only the versioning feature is honestly just a hack at best, as pointed out the ability to restore a previous version is in essence the same thing as being able to edit an item (just in one case you're manually making changes and in the other case you're restoring a snapshot of a previous state). In your specific case, with the use of a proper workflow engine (which IMO the workflow system in 4.0 was not designed to be) you would be able to specify that in a given state certain groups do not have certain permissions. Your concern is somebody being able to make changes after reaching a given state (let's call it "reviewed and published"); whether that is done through versions or manual changes in any of the fields in the editor screen is irrelevant here, you essentially need "authors do not have permission to edit at all once reaching the 'reviewed and published' state". As Joomla does not have a draft system, there isn't any practical means of saying "save these changes from an unauthorized author as a draft revision which requires review" short of saving an entirely new article (which opens its own can of worms).

Arbitrarily changing the owner is not a good idea, this should not be an automatic system behavior (well, if you want to write a plugin to do it then so be it, but it shouldn't be a core Joomla behavior).

Thanks, you get the point!

Changing the owner is not the right solution but implementing the draft concept would be the key here. IMO, this concept should be part of the workflow somewhere (since the workflows always define how to go from drafts to live versions).

I understand it means not a slight workload but again if it is not done this just illustrates the way Joomla is too often designed and continues to evolves: a mid term solution built on separately designed bricks that don't make a global professional solution.

We love Joomla! at Pulsar and we have been working with it since 2007 for rich and complex sites but too often new enhanced features (such as the new workflow) can't be used because ot it. We have to rely on third party extensions or developp our own solution.

Therefore we would love to have this draft concept implemented. I'm sorry I can't propose any developpers for it but I can pay for it ... for the love of Joomla :)

Thanks

Hi, any news on this subject please?

No news.

@pulsarinformatique If you are looking for a draft feature, please update the title of this issue to reflect what you are looking for.

Hi, while a draft feature would be a good enhancement, it was not the purpose of this topic.
I described the problem enough here and some understood it.