Moderation emails go to all staffers (can we disable or control moderation?)

[Scot Hacker]

I see some github tickets related to the moderation workflow. My question is related but different, but  thought I'd pose this question here rather than file a ticket.

We have a very broad Wagtail content structure that supports many writers and managers, using Groups and page permissions for access control. 

Page 1

Page 2

Page 3

...

Page 60

Group 1 has access to Page 1 tree and nothing else

Group 2 has access to Page 2 tree and nothing else

Group 3 has access to Page 3 tree and nothing else

etc.

This is working very well. 

We also have half a dozen people with `is_staff` access who know little about the actual content being published. Due to the nature of the content, we don't have a need for moderation features, so we haven't put anyone in the Moderators group. We didn't instruct any writers to use the Moderation feature, but some click that Moderate button anyway. The unexpected result is that  everyone with `is_staff` or superuser are receiving moderation emails. 

If we *were* to use the Moderation feature, we would want to have different moderators for different groups - the staffers don't need to see and shouldn't see those emails. Since we're not using the Moderation feature, we'd like to remove it from the menu, but we understand that menu can't be changed. Since we can't do that, can we at least intercept and bitbucket the moderation emails? (how?)

For a moment I thought I could just put a dummy user in the Moderators group and that would override the sending of email to staffers, but nope - looks like all staffers receive a copy of all moderation emails.

Suggestions?  Thanks.

[Scot Hacker]

Proposal: Change the default behavior so that moderation emails are *only* sent to people in the Moderators group. `is_staff` is not a very good criteria for deciding who should receive those emails. This change would not address the more complex question of fine-grained moderation per page/group, but it would at least stem the flow of emails going to people who have nothing to do with the content. 

Thanks.

BTW can you tell we just launched our first WT project to campus? :)

People are generally loving the interface and workflow, and things are going very well. Thanks for a great CMS!

[Scot Hacker]

My manager says: "In an ideal world, we should be able to turn moderation on or off at various points in the content tree, and be able to specify who the moderator(s) should be at each node." This sounds logical to me.

[Tom Dyson]

Hi Scot

Do you know about the notification preferences UI at /admin/account/notification_preferences/ (accessed from your avatar -> Account Settings)? Most of your users may prefer to uncheck this.

We'd previously de-prioritised extensible workflow as an enterprisey feature that most people don't really need, but we've heard of some convincing use-cases recently, so it's back on the agenda.

Great to hear about your Wagtail launch! Can you share any URLs / screenshots?

Best wishes

Tom

[Scot Hacker]

On Wed, Jan 18, 2017 at 11:17 AM, Tom Dyson <t...@torchbox.com> wrote:

Hi Scot

Do you know about the notification preferences UI at /admin/account/notification_preferences/ (accessed from your avatar -> Account Settings)? Most of your users may prefer to uncheck this.

Ah, that does help. And that allowed me disable these emails from the shell for all users. That leaves the Moderation menu item in place, which could be confusing, but we'll train users not to use it for now. Thanks.

 

We'd previously de-prioritised extensible workflow as an enterprisey feature that most people don't really need, but we've heard of some convincing use-cases recently, so it's back on the agenda.

Great to hear about your Wagtail launch! Can you share any URLs / screenshots?

Sure thing - the CCA Portal is a standard Django project. Up until now we've dealt only with data coming from external sources. Yesterday we launched  a new Shops and Services directory, which brings all of CCA's "shop" resources (metal shop, ceramics studio, etc.) together  in one place:

https://portal.cca.edu/shops/

Its content is managed by individual human shop managers rather than external data sources, so we used Wagtail to provide a human-friendly content management experience for them. We're taking full advantage of WT's hierarchical content tree / permissions system. 

The front page / directory is powered by a cached django JSON endpoint, made interactive and sortable with React. Individual shop pages are pure Wagtail. Some shops also include embedded Google Calendar data, e.g. https://portal.cca.edu/shops/rps/3d-printer-services/ . Shops can also have sub-shops, dedicated Tool pages with more details for a given tool, and there is an optional "shop news" system in place as well.

We've been busy training the managers how to use the new system and that process has gone well. 

This is the first version - it will evolve a lot over the next few months. And we have many other content areas coming to Portal that will likely also use Wagtail. 

Best,

Scot

--

Scot Hacker

Web Application Developer

California College of Arts

510.594.5019 / sha...@cca.edu