Consider making moderation forum specific

[mdawaffe]

http://bbpress.org/forums/topic/75

This could be considered closed as so10 has created a plugin for this as well.

http://bbpress.org/forums/topic/403?replies=4

Trent

I think it still needs to be a core forum functionality.

Then let's reopen.

The first step is to make sure we use the right caps everywhere and to make sure they're robust enough.

(In [728]) Clean up edit_deleted cap. It should only be used in meta caps. re #459

#155 #493 #515 #686 #732

Leaving this one in the "maybe later" pile for now.

Still valid today and often requested even for bbPress 2.0. Moving to 2.1 to research in next release.

Moving to future release. Should be done in 2.2.

Looking forward to this in 2.2 - definitely a very common request and well be a very welcomed feature.

Anybody with any ideas on the best setup for this? The old plugin linked from the original thread posted in the ticket description had the forum moderators setup under the Users menu.

Would this still be an acceptable place for the menu to be or should it be placed somewhere else?

Also, what would be the best place to store the access info? I'm guessing usermeta table with its own row? Would like to work on this to expand my skills but don't want to get too far into it only to have it shot down and require major changes and essentially waste time.

Replying to JarretC:

Anybody with any ideas on the best setup for this? The old plugin linked from the original thread posted in the ticket description had the forum moderators setup under the Users menu.

Also, what would be the best place to store the access info? I'm guessing usermeta table with its own row? Would like to work on this to expand my skills but don't want to get too far into it only to have it shot down and require major changes and essentially waste time.

For a first pass, store an array of user_id's in each forum's postmeta. We can map the 'moderate' cap to the user as we need to after the fact.

This setting will really only be relevant on the forum page. I can see needing to query it from either direction, but we're stuck either way and building a UI inside the profile area to assign which forums to what users is beyond the scope of this ticket.

also keep in mind the future bbpress->buddypress group forums and that bbpress may need to know about bp_group_admin_mods_...

maybe mimic the same functions/setup from buddypress but using roles/cap instead of db flags

Replying to etivite:

also keep in mind the future bbpress->buddypress group forums and that bbpress may need to know about bp_group_admin_mods_...

maybe mimic the same functions/setup from buddypress but using roles/cap instead of db flags

Exactly. We'd map the 'moderate' cap to a user based on what forum they are viewing. Agree we'd want to play nicely with BuddyPress group moderators too.

That said, running out of time in 2.2 to do this, so moving to future release.

Moving to 2.3.

Proof-of-concept: forum-mod taxonomy with AJAX-suggested user nicenames.

I like this. The metabox idea is familiar, and an easy win. I think I'm okay with being able to add usernames that don't exist too. Suggesting names says "hey we found these matches" and letting the user add what they want says "hey, that's cool... whatevs."

Uses get_users() instead of direct query

In the interest of possibly extending taxonomies to include participate and spectate for better ACL support, changed forum moderator taxonomy from 'forum-mod' to 'bbp-moderate'; helper functions in progress but I need to test them more thoroughly before dealing with assigning/modifying capabilities based on forum.

Helper functions.

Replying to jmdodd:

In the interest of possibly extending taxonomies to include participate and spectate for better ACL support, changed forum moderator taxonomy from 'forum-mod' to 'bbp-moderate'; helper functions in progress but I need to test them more thoroughly before dealing with assigning/modifying capabilities based on forum.

This makes sense to me. Also opens the door back up for Bozo support, too.

Helper functions in 459.3.diff have been tested and are working fine with test users and assigning them to moderate forums. Getting back expected results re: forum moderators and moderator's forums.

Rough numbers for the current codebase (r4532):

~200 instances of 'current_user_can', including the following functions that look like they could be consolidated:

• bbp_current_user_can_publish_forums(), bbp_current_user_can_access_create_forum_form(),
• bbp_current_user_can_publish_topics(), bbp_current_user_can_access_create_topic_form(),
• bbp_current_user_can_publish_replies(), bbp_current_user_can_access_create_reply_form().

12 instances of 'bbp_user_can_view_forum'.

20 instances of 'user_can'.

Possibilities:

• Rolling our own bbp_user_can() (bbp_current_user_can()?) and trying to figure out what we're asking permission for via globals. I'd rather not get too far divorced from WordPress on capability handling so this is not really my favorite solution.
• A thorough audit to make sure that the relevant forum/topic/reply ids are being passed to current_user_can(), and that the right caps are being checked.
• Filtering on user_has_cap might also work, but I think passing explicit forum/topic/reply ids is preferable to relying on global values.

Looking like a bit of a rabbit hole, so let's move this off to 2.4. This gives us time to iterate on these other architectural issues until then.