[buddypress-trac] [BuddyPress Trac] #5553: BP 2.0 upgrade routine improperly deletes existing user roles if activation_key usermeta is present

buddypress-trac noreply at wordpress.org
Thu Apr 17 00:25:23 UTC 2014


#5553: BP 2.0 upgrade routine improperly deletes existing user roles if
activation_key usermeta is present
--------------------------+-------------------
 Reporter:  boonebgorges  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  highest       |  Milestone:  2.0.1
Component:  Core          |    Version:
 Severity:  critical      |   Keywords:
--------------------------+-------------------
 In WP non-Multisite prior to BP 2.0, the user registration workflow worked
 like this:

 1. At registration, a user is created with user_status=2 and a usermeta
 with the key 'activation_key'
 2. Activation email is sent
 3. When the activation URL is loaded, (a) user_status is switched to 0,
 and (b) the activation_key usermeta is deleted

 The switch to the wp_signups schema for signups in BP 2.0 includes a
 migration tool that moves old-style unactivated signups to the new system.
 It identifies signups as those WP users that have an activation_key value
 in usermeta. https://buddypress.trac.wordpress.org/browser/tags/2.0/bp-
 core/bp-core-update.php#L353 Then, as part of the migration, it deletes
 `capabilities` and `user_level` usermeta for the user, to keep them out of
 regular user lists. (See line 391-393.)

 It turns out (see http://buddypress.org/support/topic/lost-admin-access-
 after-2-o-update/) that there are situations where a user can be activated
 but still have the activation_key value in the DB. The result: when the
 migration routine runs, these users are identified incorrectly as
 unactivated signups, and their roles are improperly revoked.

 There are probably various ways in which the activation_key could be
 retained for activated users. One concrete one I've identified is the use
 of this plugin http://wordpress.org/plugins/bp-disable-activation/, which
 activates the user by switching the user_status to 0 but does *not* delete
 activation_key.

 I'll follow up with suggested fixes.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5553>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list