Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4930 closed defect (bug) (fixed)

Changing user's group status via group admin looses forum settings

Reported by: djpaul's profile DJPaul Owned by:
Milestone: 1.7.1 Priority: normal
Severity: normal Version: 1.7
Component: Administration Keywords:
Cc:

Description

Originally reported at http://buddypress.org/support/topic/bug-saving-changes-in-the-new-wp-admin-groups-section-removes-bp-forum/#post-161601

In my testing, changing the role of a group member seems to unset the "we want to have a group forum" checkbox. Changing the group name or description doesn't unset the forum setting.

Change History (6)

#1 @boonebgorges
12 years ago

I assume that this is the bbPress 2.x box, not the bbPress 1.x "Enable discussion forum" box?

Can you verify your version of bbPress 2.x? There were some changes between 2.2.x and 2.3 that might be relevant.

See also #4919, which may be related.

#2 @DJPaul
12 years ago

Yes, bbPress 2.

Latest versions: bbPress trunk r4855, BuddyPress trunk r6909

#3 @boonebgorges
12 years ago

Thanks. I'm having a hard time reproducing the problem.

  1. Dashboard > Groups > Edit
  2. For an existing group member, change role (eg Administrator to Member)
  3. Double-check that 'Yes, I want this group to have a forum' is checked
  4. Hit 'Save Changes'
  5. Page refreshes with user role changed, and with 'Yes...' checkbox checked, as expected.

I've tested the same thing with different scenarios in 2 - removing members from groups, different kinds of demotion, etc. Can't reproduce it.

Am I doing it right?

#4 @boonebgorges
12 years ago

OK, I've successfully reproduced. Looks like the problem only happens when you attempt to remove every Administrator from a group - when the handler hit that error, it redirected without processing the rest of the form, including hook for plugins like bbPress.

#5 @boonebgorges
12 years ago

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

(In [6912]) Don't redirect immediately after attempting to remove all admins from a group

On the original implementation, when you attempted to remove all admins from a
group via the Dashboard panel, you were immediately redirected away from the
screen, without the rest of the script being processed. This meant, in
particular, that the bp_group_admin_edit_after action was not run, with the
result that plugins weren't able to save their options properly in this
scenario.

This changeset modifies the process so that, in the case of this kind of error,
the redirection doesn't happen until the end of the form handler, allowing
plugins to hook into the save routine correctly.

Fixes #4930

#6 @boonebgorges
12 years ago

(In [6913]) Don't redirect immediately after attempting to remove all admins from a group

On the original implementation, when you attempted to remove all admins from a
group via the Dashboard panel, you were immediately redirected away from the
screen, without the rest of the script being processed. This meant, in
particular, that the bp_group_admin_edit_after action was not run, with the
result that plugins weren't able to save their options properly in this
scenario.

This changeset modifies the process so that, in the case of this kind of error,
the redirection doesn't happen until the end of the form handler, allowing
plugins to hook into the save routine correctly.

Fixes #4930

Note: See TracTickets for help on using tickets.