Skip to:
Content

bbPress.org

Opened 18 years ago

Closed 8 years ago

Last modified 7 years ago

#459 closed task (blessed) (fixed)

Consider making moderation forum specific

Reported by: mdawaffe's profile mdawaffe Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: 2.6 Priority: high
Severity: normal Version: 0.7.2
Component: API - Moderation Keywords: fixed-major
Cc: vpundir@…, jmdodd@…, stephen@…, jared@…, mercijavier@…, hamzahali@…, pericam@…, jjjay@…

Attachments (10)

459.1.diff (8.0 KB) - added by jmdodd 12 years ago.
Proof-of-concept: forum-mod taxonomy with AJAX-suggested user nicenames.
459.2.diff (8.1 KB) - added by johnjamesjacoby 12 years ago.
Uses get_users() instead of direct query
459.3.diff (14.8 KB) - added by jmdodd 12 years ago.
Helper functions.
leap-bbpress-permissions.zip (19.6 KB) - added by smithwib 11 years ago.
Proposed user and group permissions plugin
459.4.diff (15.3 KB) - added by netweb 11 years ago.
459.diff (18.5 KB) - added by johnjamesjacoby 11 years ago.
Cleaned up and mostly working. Needs testing.
459.5.diff (19.1 KB) - added by netweb 10 years ago.
459.6.diff (23.9 KB) - added by netweb 9 years ago.
459.7.diff (24.0 KB) - added by netweb 9 years ago.
Minor tweaks…
459.8.diff (24.7 KB) - added by tharsheblows 9 years ago.
needs refactoring to not be so redundant

Download all attachments as: .zip

Change History (95)

#1 @Trent
18 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

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

Trent

#2 @so1o
18 years ago

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

#3 @mdawaffe
18 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#4 @mdawaffe
18 years ago

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

#6 @sambauers
16 years ago

  • Milestone changed from 1.0 to 1.5

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

#7 @kevinjohngallagher
15 years ago

  • Priority changed from normal to high

#8 @johnjamesjacoby
13 years ago

  • Milestone changed from Future Release to 2.1
  • Version 0.7.2 deleted

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

#9 @johnjamesjacoby
13 years ago

  • Milestone changed from 2.1 to Future Release

Moving to future release. Should be done in 2.2.

#10 @johnjamesjacoby
13 years ago

  • Milestone changed from Future Release to 2.2

#11 @jaredatch
13 years ago

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

#12 @JarretC
13 years ago

  • Cc JarretC added

#13 follow-up: @JarretC
13 years ago

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.

#14 in reply to: ↑ 13 @johnjamesjacoby
12 years ago

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.

#15 follow-up: @etivite
12 years ago

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

#16 @sooskriszta
12 years ago

  • Cc vpundir@… added

#17 in reply to: ↑ 15 @johnjamesjacoby
12 years ago

  • Component changed from Administration to Moderation
  • Milestone changed from 2.2 to Future Release

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.

#18 @johnjamesjacoby
12 years ago

  • Milestone changed from Future Release to 2.3

Moving to 2.3.

#19 @jmdodd
12 years ago

  • Cc jmdodd@… added

#20 @netweb
12 years ago

  • Cc stephen@… added

@jmdodd
12 years ago

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

#21 @johnjamesjacoby
12 years ago

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

@johnjamesjacoby
12 years ago

Uses get_users() instead of direct query

#22 follow-up: @jmdodd
12 years ago

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.

@jmdodd
12 years ago

Helper functions.

#23 in reply to: ↑ 22 @johnjamesjacoby
12 years ago

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.

#24 follow-up: @jmdodd
12 years ago

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.

#25 @johnjamesjacoby
12 years ago

  • Milestone changed from 2.3 to 2.4

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.

#26 @jaredatch
12 years ago

  • Cc jared@… added

#27 @mercime
12 years ago

  • Cc mercijavier@… added

#28 @johnjamesjacoby
12 years ago

  • Milestone changed from 2.4 to 2.5

No movement in a while. No time for 2.4. Moving to 2.5.

#29 @johnjamesjacoby
11 years ago

  • Milestone changed from 2.5 to 2.6

2.5 is going to focus on performance improvements. Moving to 2.6.

#30 @johnjamesjacoby
11 years ago

  • Milestone changed from 2.6 to 2.7

Bump to 2.7.

#31 @netweb
11 years ago

Related: #1721

@smithwib
11 years ago

Proposed user and group permissions plugin

#32 follow-up: @smithwib
11 years ago

Per John James Jacoby's suggestion, I've uploaded the draft version of a plugin I wrote. It optionally works with the User Groups plugin by Katz Web Services if installed. It needs some TLC by experts in actions + filters, I18N, etc.

@netweb
11 years ago

#33 @netweb
11 years ago

In 459.4.diff:

Refresh of 459.3.diff to apply cleanly against /trunk

#34 in reply to: ↑ 32 @netweb
11 years ago

Replying to smithwib:

Per John James Jacoby's suggestion, I've uploaded the draft version of a plugin I wrote. It optionally works with the User Groups plugin by Katz Web Services if installed. It needs some TLC by experts in actions + filters, I18N, etc.

@smithwib Thanks for the upload, will take a look at your plugin soon.

#35 follow-up: @johnjamesjacoby
11 years ago

Really liking the progress on patches here. There are a few things I'd like to tweak, but overall think this is the way to go. With a patch attached, I'm wondering if we can move this to 2.6, and move bbPress comments to 2.7.

#36 in reply to: ↑ 35 @netweb
11 years ago

Replying to johnjamesjacoby:

I'm wondering if we can move this to 2.6, and move bbPress comments to 2.7.

Either/or, I've been looking at this with the goal of 'bozo' functionality as bbPress v2.x starts appearing (and/or thinking of appearing) on more wordpress.org sites.

Also of note is 'bbPress Per Forum Moderation' is part of @dragooon's (Shitiz Garg) GSoC proposal.

@johnjamesjacoby
11 years ago

Cleaned up and mostly working. Needs testing.

#37 @johnjamesjacoby
11 years ago

  • Keywords needs-testing added
  • Milestone changed from 2.7 to 2.6
  • Type changed from enhancement to task

#38 @johnjamesjacoby
11 years ago

The only problem I see with this patch is get_objects_in_term() is not cached, meaning we'll need to add our own setting/busting for this on CRUD actions.

#39 @johnjamesjacoby
11 years ago

wp_get_object_terms() usage needs to be checked to make sure caching is sufficient also.

#40 @JarretC
11 years ago

  • Cc JarretC removed

#41 @netweb
11 years ago

Do we want to list the forums moderators anywhere?

Below screenshot/hack in the forum template notice and/or after the forum description.

https://i.cloudup.com/l6rfiE5s3Z.png

Looking at that above if it was to be in the template notice something more along the lines of:

This forum is moderated by User123, contains 2 topics and 3 replies, and was last updated by admin 2 weeks ago.

I think I may have just answered my own question as to a decision or option, if a forum as 10 moderators this will get ugly quite quickly...

#42 follow-up: @netweb
11 years ago

Testing 459.diff 'Forum Moderator' vs 'Moderator' capability checks:

  • 'Moderator' can 'edit others topics' - 'Forum Moderators' cannot
  • 'Moderator' can 'edit topic tags' - 'Forum Moderators' cannot
  • 'Moderator' and 'Forum Moderators' can merge, split, close, stick and spam topics/replies

#43 in reply to: ↑ 42 ; follow-up: @johnjamesjacoby
11 years ago

Replying to netweb:

Testing 459.diff 'Forum Moderator' vs 'Moderator' capability checks:

  • 'Moderator' can 'edit others topics' - 'Forum Moderators' cannot
  • 'Moderator' can 'edit topic tags' - 'Forum Moderators' cannot
  • 'Moderator' and 'Forum Moderators' can merge, split, close, stick and spam topics/replies

This seems fine to me, and the desired result IMO.

#44 in reply to: ↑ 43 @netweb
11 years ago

Replying to johnjamesjacoby:

This seems fine to me, and the desired result IMO.

Cool

#45 @netweb
11 years ago

Whilst digging around with topic and reply moderation I found a few issues with topics and replies whose post status is pending.

You cannot view any topics or replies with status pending on the front end, forum moderator, moderator or keymaster included. This includes using the view=all query string.

To view topics and replies and approve them you must be a keymaster and approve them from the backend.

#46 @hamzahali
11 years ago

  • Cc hamzahali@… added

I did testing for this one, seems working fine, only the add moderator option in forums menu (admin area) seems to be of no use, Till when can we expect this to be included in the core.

#47 @netweb
11 years ago

hamzahali,

When you are editing a forum when you start typing a name it will populate a dropdown with a list of usernames. At this stage this is expected to be included with the next version of bbPress, though that is not 100% decided just yet.

https://i.cloudup.com/UMvAHIbFIH.png

#48 @hamzahali
11 years ago

I have done lots of testing of this one, and it seems 100% fine

#49 follow-up: @dreamwork
10 years ago

The last file, includes/users/functions.php
I couldn't find anywhere to place the code!! Then I just have it placed on the bottom, and I fail!

What version you guys test it for?

#50 in reply to: ↑ 49 @netweb
10 years ago

Replying to dreamwork:

The last file, includes/users/functions.php
I couldn't find anywhere to place the code!! Then I just have it placed on the bottom, and I fail!

What version you guys test it for?

You need to apply the patch against the bbPress development source code, see the WordPress handbook on working with patches here (and related references in the handbook). If you have any other questions please post on the support forums https://bbpress.org and I'll answer them there as discussing them here in this ticket is not the place for these discussions.

#51 @netweb
10 years ago

In 459.5.diff a refresh of 459.diff to apply cleanly against /trunk

@netweb
10 years ago

#52 @sambauers
10 years ago

I hope this ticket never closes. I use the email notifications to remind me which decade I'm in.

#53 @johnjamesjacoby
10 years ago

  • Milestone changed from 2.6 to 3.0

Moved to 3.0, due September 15, 2020. :)

Last edited 10 years ago by johnjamesjacoby (previous) (diff)

This ticket was mentioned in Slack in #meta by jjj. View the logs.


10 years ago

#56 @netweb
10 years ago

  • Milestone changed from 3.0 to 2.6

Let's get this into 2.6 and stop being a cheat sheet for @sambauers ;)

p.s. New Year, Same Decade

#57 @Stagger Lee
9 years ago

  • Cc pericam@… added

This ticket was mentioned in Slack in #meta-i18n by netweb. View the logs.


9 years ago

@netweb
9 years ago

#59 in reply to: ↑ 24 @netweb
9 years ago

Have refreshed the existing patches in 459.6.diff: with updated docs, formatting a few minor fixes.
I'm currently writing a bunch of unit tests outlined in comment:24
Still yet to look at get_objects_in_term() and caching mentioned in comment:38
Also needing to look at wp_get_object_terms() caching mentioned in in comment:39:
Merging this should be good to go, merging sooner rather than later so another refresh isn't needed, iterate further once committed.

#60 @sambauers
9 years ago

Hi Stephen!

http://www.vh1.com/news/wp-content/uploads/2015/07/th-2-1436452593.gif

@netweb
9 years ago

Minor tweaks...

#61 @johnjamesjacoby
9 years ago

In 5834:

Moderators: First pass at per-forum moderators.

This commit introduces a powerful feature commonly found in other popular forum software that has been on our wishlist for nearly 9 years. It includes the following changes:

  • Custom forum-mod taxonomy for assigning user nicenames to forum IDs
  • Associated functions for defining capabilities, labels, etc...
  • New capability filters for ensuring forum moderators have the ability to moderate forums even without the moderator role assignment
  • New option for toggling the entire feature on/off (on by default)

Props jmdodd, netweb. See #459.

#62 @johnjamesjacoby
9 years ago

In 5835:

Moderators: Introduce none argument for topic-tags & forum-mods list functions.

This change allows for passing text or HTML to output if no taxonomy terms are found, and uses this new functionality in wp-admin to show per-forum moderators in the list-table column, also reducing code duplication.

See #459.

#63 @johnjamesjacoby
9 years ago

In 5836:

Moderators: Add forum moderators field to form-forum.php template part. See #459.

#64 @johnjamesjacoby
9 years ago

In 5837:

Terms: Update functions for getting terms & term names to be more flexible & reusable by other functions. See #459.

#65 @johnjamesjacoby
9 years ago

In 5838:

Moderators: Introduce functions for theme-side setting & getting of forum mods for form-forum.php. See #459.

#66 @johnjamesjacoby
9 years ago

In 5839:

Moderators: Rename bbp_get_forum_mod_ids() to bbp_get_forum_moderator_ids() to better match unabbreviated forum equivalent. Also update phpdoc & refactor some logic to use cached functions. See #459.

#67 @johnjamesjacoby
9 years ago

In 5841:

Moderation: Fix some copy-pasta and make sure form terms are formatted correctly. See #459.

#68 @johnjamesjacoby
9 years ago

  • Keywords needs-testing removed
  • Resolution set to fixed
  • Status changed from reopened to closed

Let's call this "fixed" and open new tickets for new issues & enhancements, likely in 2.7.

Sam, you may want to find a new ticket to subscribe to. <3

This ticket was mentioned in Slack in #bbpress by netweb. View the logs.


9 years ago

This ticket was mentioned in Slack in #bbpress by netweb. View the logs.


9 years ago

#71 @tharsheblows
9 years ago

  • Cc jjjay@… added

Sorry, I'm not quite sure if I should add this here or open a new one or what. Anyway, here's a slightly different way of doing it with some more admin bits.

@tharsheblows
9 years ago

needs refactoring to not be so redundant

#72 @johnjamesjacoby
9 years ago

In 6032:

Moderators: pass current forum/topic/reply ID into moderate capability checks, providing additional context about what's being moderated so more targeted decisions can be made.

See #459.

#73 @sambauers
9 years ago

I can't believe it's over!

http://www.electricdreaming.com/wp-content/uploads/2015/10/fabio.jpg

#74 @johnjamesjacoby
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Zombie ticket.

Reopen so per-forum moderators can be refactored to use metadata vs. mock-taxonomy.

#75 @johnjamesjacoby
9 years ago

In 6056:

Moderators: Refactor per-forum moderators to use meta-data instead of mocked taxonomy terms.

If the future of Forums is a taxonomy (vs. a custom post-type) then a per-forum Moderator taxonomy for a Forum taxonomy won't work very well, for a few reasons:

  • Scalability
  • Taxonomies for taxonomies is a bit more inception than should be required for this simple feature
  • Forum moderators do not require much of what taxonomy objects provide (permalinks, visibility, metadata, etc...)
  • User taxonomy terms matching nicenames works okay for something like Automattic's P2 theme, but bbPress requires a user ID based solution to avoid data synchronization issues between nicenames & term slugs

So... the future of per-forum per-user capability mappings is in meta-data using map_meta_cap.

This commit:

  • Removes the forum_mod taxonomy and surrounding code additions introduced in the first pass in r5834
  • Renames forum_mod functions to forum_moderator to be more explicit
  • Adds CRUD wrapper functions for per-forum moderator meta data
  • Adds administrative interfaces for assigning moderators to forums for wp-admin and forum edit pages
  • Adds helper functions for getting user nicenames & IDs

Note that this feature has now been refactored to no longer be forum specific (I.E. object agnostic) -- it's possible for any user access to be mapped based on the object type using any meta-data key. While this is currently useful for per-forum moderators, it may be user for per-topic blocking, per-topic-tag moderation, etc...

See #459.

#76 @netweb
8 years ago

The ticket that keeps on giving!

http://blog.teddythedog.com/wp-content/uploads/2014/12/Gift-the-Keeps-on-Giving_FB.jpg

#77 @johnjamesjacoby
8 years ago

In 6221:

Moderators: Update bbp_get_moderator_forum_ids() to use same approach as favs/subs.

See #459, #2959, #2972.

#78 @johnjamesjacoby
8 years ago

  • Owner set to johnjamesjacoby
  • Status changed from reopened to new

#79 @johnjamesjacoby
8 years ago

  • Keywords fixed-major added
  • Resolution set to fixed
  • Status changed from new to closed
  • Version set to 0.7.2

👾 👾 👾 👾 👾 👾

👾 👾 👾 👾 👾 👾

👾 💥 👾 👾 👾 👾

🚀

Last edited 8 years ago by johnjamesjacoby (previous) (diff)

#82 @johnjamesjacoby
8 years ago

In 6273:

Forums: Add howto text to bbp_moderator_assignment_metabox().

See #459.

#83 @johnjamesjacoby
7 years ago

In 6519:

Moderators: Add an $object_type parameter to add/remove/delete functions.

In a future release, this will more easily allow objects like taxonomy-terms to have their own moderators, and is also necessary for future enhancements to the WordPress.org support forums where custom taxonomies are used for prevalently than in bbPress core currently.

See #3068, #459.

#84 @johnjamesjacoby
7 years ago

In 6692:

Classes: add more author & moderator related CSS classes to helper functions.

This change adds classes to forums, topics, and replies where the respective author is also a moderator of the nearest parent forum.

See #459.

This ticket was mentioned in Slack in #bbpress by jjj. View the logs.


7 years ago

#86 @johnjamesjacoby
7 years ago

In 6739:

Engagements: include BBP_User_Engagements_Term class, as term storage example.

This change includes an alternative storage mechanism for engagements. Meta is used by default, but using Taxonomies and Terms for storage instead may be more appealing to certain installation types.

A few related functions were updated to use newer abstractions. See #459.

Note: See TracTickets for help on using tickets.