CMS_MODERATOR and 2.4

[David Bell]

Hi,

I noticed in the docs that CMS_MODERATOR "will be deprecated in 2.4 and replaced with a simpler way of handling unpublished changes"

Where can I find out what is coming in 2.4? (and when it may arrive?)

Workflow/moderation is the one thing that is limiting the choice of django-cms for some of our projects.

Many thanks
Dave

[laurent alsina]

Hi,

just in case a few hints about this here: https://groups.google.com/forum/?fromgroups=#!searchin/django-cms/moderator/django-cms/EtSzCmEnQOY/hjLqMGm8FiMJ  

it's hard to get a high enough genericity/complexity ratio on publication workflows, I'm going for a quite needs-specific implementation on my project.

Laurent

[Björn Sandberg]

Hi all,

I just started looking into django-cms on behalf of a client with a fairly large page count (1000+). We are evaluating several different solutions, and as django is in common use elsewhere this is looking like a good solution. However, a proper workflow for publishing is essential, so until the current issues with the toolbar and moderation is resolved, I can't really recommend it for live deployment.

I've received some time to see if this might be resolved, so I'm willing to take it on unless someone else is already working on it. I'd prefer not to step on anyone's toes. I'm also somewhat unclear on what the intention is for 2.4 other than general remarks. Is there a list of use cases anywhere?

What we'd like to see from our perspective is something like this:

• The distinction between moderated and unmoderated sites goes away. A site with no moderators treats all editors as moderators, but there's still a separate action to publish changes to the public version.
• Moderator lists are managed on a basis of "this page and all descendants", ideally using groups (we use an LDAP auth backend). To have a different permission level for a subsection of the page hierarchy, simply edit that subsection's top page. This allows for tightly restricted top nodes, with more liberal policies for subsections. Ideally, it should be possible to hook something like Arkestra into this for those that need it.
  
• Editor lists can also be managed in the same fashion. This would break the simple "has staff access -> can edit" rule currently in place.
• A "revert" action to scrap differences in the draft from the public version. This also allows for easy migration of existing sites, especially if the toolbar issue has caused the two versions to diverge.
  

We have a pretty simple workflow, i.e. edit -> request moderation -> moderator approval -> published. Are there more complex workflows that must be taken into account?
Generally speaking, if there is any kind of project documentation / wiki I'd love to have a read of what the idea is.

Other than that, what's the current idea about release date for 2.4?

Cheers,

// Björn

[Dan Peade]

Not sure if you've already seen this but Jonas' reply in  thread is pretty specific, it might shine a bit of light on future plans for you:

https://groups.google.com/forum/?fromgroups=#!searchin/django-cms/Guillaume$20Piot/django-cms/IEzFvuIGAsA/BuHEz1cxdQQJ

Cheers,
Dan

[digi604]

Hi,

At the moment the plan is to remove the moderator. And to only have a draft and public version per page.

In the toolbar we will have 2 buttons:

publish

and

revert from live

So the whole "we send out emails when you request moderation" workflow falls out. It has proven to not be used by our clients.
Hierarchical publishing… aka… i publish this site and every child page gets published as well and every plugin and model that extends from publisher… will probably go away as well.

For input let's discuss here:

https://github.com/divio/django-cms/issues/1458

[Daniele Procida]

On Mon, Oct 1, 2012, Björn Sandberg <adapti...@gmail.com> wrote:

>I just started looking into django-cms on behalf of a client with a fairly
>large page count (1000+). We are evaluating several different solutions,
>and as django is in common use elsewhere this is looking like a good
>solution. However, a proper workflow for publishing is essential, so until
>the current issues with the toolbar and moderation is resolved, I can't
>really recommend it for live deployment.

Hi Björn.

When we were in your position three or four years ago, moderation was part of our specification.

However, It was quite complicated to get working, so we decided just to do without it for the time being.

Some years later, our site is deployed with 1300+ pages and about 60 different web authors, and as it turns out, we haven't missed that functionality at all.

Now, even if it were easy, we wouldn't bother using it - why introduce a layer that just gets in the way and solves a problem that we don't actually have?

Our web authors work for different departments and office; they're in Groups. Each Group has permission to edit its own Pages ("has permission to edit this page and all descendants") - and that has worked perfectly well so far, with no need for moderation/approval mechanisms.

Obviously this might not work quite so well for a different organisation, but in our case it has been wholly adequate.

I also give a few trusted web editors extra permissions by adding them to a Group called "Lead web editors", just so that the power to cause damage by mistake is more limited, but probably you would want to do that sort of thing anyway.

Daniele

[Jonas Obrist]

While I'll most likely re-iterate what has been said already, I'd like to give my opinion and reasoning why I was strongly for a move away from the current situation.

The main issue with the current moderation workflow (permissions, moderation, publisher), I'll call it permmod, is that it's insanely complex both in the code and in the UI. I know of one site that uses it, but even that site doesn't fully use it.

The reason I really wanted to get rid of this is because nobody in the core team currently fully understands what's going on there, and that's a huge problem. The whole permmod slowed down our development process a lot because there would always be bugs related to it when we did changes. And because hardly anybody I know uses it, it's hard to get feedback on it.

So the plan I had moving forward is simple: KILL IT. But add something much simpler that hopefully covers a lot more use cases.

The initial idea was to have a non-hierarchical permission 'can_publish'. And I think we should stick to this for the next release. If there's sufficient interest and we find a maintainable way to implement it, we might build a more advanced workflow on top of this new (hopefully a lot simpler) solution.

What would be very interesting is if this potential future advanced workflow system could live outside the cms core itself. What kind of APIs would we have to expose to make this possible?

Jonas

[Jonas Obrist]

Please read http://bit.ly/cms-moderator-future

On Friday, August 31, 2012 11:58:38 AM UTC+2, David Bell wrote:

[Kaspars Sprogis]

Quote from page:  This feature will most likely be enabled by default, and it might not even be optional.

 

I really hope it will be optional, let's not forget there is development state for each site, also there are internal sites/decuments and so on, that we can edit and that doesn't need so secure publish mechanism. Specially in development mode it is quite annoying that after every save, you have to publish content again. Change few commas -> save -> republish...

It should totally be configurable, maybe even per user or at least in config.. Thank you