[4.0] Com_content: Allowing the versioning control on some user groups only

[pulsarinformatique]

Isn't it possible to add a "edit versions' permission in com_content so that only some given user groups could actually get access to the version control ?

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

thanks

[bembelimen]

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

[pulsarinformatique]

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

[pulsarinformatique]

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

[ghost]

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

[pulsarinformatique]

hello

yes, definitively !
thanks

cyril

[ghost]

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

[bembelimen]

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?

[pulsarinformatique]

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

[bembelimen]

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?

[Bakual]

Right now ANYONE can access the VERSION button .

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

[brianteeman]

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

[pulsarinformatique]

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

[brianteeman]

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?

[pulsarinformatique]

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.

[brianteeman]

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

[pulsarinformatique]

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.

[Bakual]

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.

[pulsarinformatique]

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

[pulsarinformatique]

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

[brianteeman]

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?

[pulsarinformatique]

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

[ot2sen]

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.

[pulsarinformatique]

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?

[mbabker]

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

[pulsarinformatique]

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

[pulsarinformatique]

Hi, any news on this subject please?

[Bakual]

No news.

[jwaisner]

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

[pulsarinformatique]

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.

[pulsarinformatique]

Sorry again joomla devs don't understand real life usages :(