|CMS_MODERATOR and 2.4||David Bell||8/31/12 2:58 AM|
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.
|Re: CMS_MODERATOR and 2.4||laurent alsina||9/14/12 7:27 AM|
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.
|Thierno Diop||9/16/12 7:45 AM||<This message has been deleted.>|
|Re: CMS_MODERATOR and 2.4||Björn Sandberg||10/1/12 5:39 AM|
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:
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?
|Re: CMS_MODERATOR and 2.4||Dan Peade||10/1/12 4:23 PM|
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:
|This message has been hidden because it was flagged for abuse.|
|Re: CMS_MODERATOR and 2.4||Daniele Procida||10/1/12 9:02 AM|
On Mon, Oct 1, 2012, Björn Sandberg <adapti...@gmail.com> wrote: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.
|Re: CMS_MODERATOR and 2.4||Jonas Obrist||10/2/12 2:20 AM|
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?
|Re: CMS_MODERATOR and 2.4||Jonas Obrist||10/3/12 7:02 AM|
|Re: CMS_MODERATOR and 2.4||Kaspars Sprogis||3/10/13 12:01 PM|
Quote from page: This feature will most likely be enabled by default, and it might not even be optional.
It should totally be configurable, maybe even per user or at least in config.. Thank you