Skip to:
Content

BuddyPress.org

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#8582 closed enhancement (fixed)

Add site membership requests.

Reported by: dcavins's profile dcavins Owned by: dcavins's profile dcavins
Milestone: 10.0.0 Priority: normal
Severity: normal Version: 9.1.1
Component: Members Keywords: commit
Cc: dcavins

Description

It would be very useful to be able to screen site members on the way in, rather than dealing with spam users who have registered and gained access to the site immediately.

I've built a first working patch that interrupts the registration flow, so that a site admin must manually intervene to send the activation email to the user. Here's a comparison of the normal registration flow with the proposed request-based flow:

BuddyPress normal sign-up process:
User fills out registration form.
User is created in signups table with active = 0.
User is created in users table with status = 2
BuddyPress sends user an activation email.
User follows link in email to activate account.
User receives welcome email from BP site.
Table updates: signups entry now is active, user status is now 0.

Membership request sign-up process:
Admin disables "Anyone can register" and enables membership requests.
User visits registration form which has been recast as a "Request Membership" form.
Site admins receive email and notifications about the pending request.
Site admin can manage via the "manage signups" interface.
Admin can check the user's registration information via the extended profile view.
Admin approves the user and the activation email is sent.
User follows link in email to activate account.
User receives welcome email from BP site.

Notes:
If an email has been sent, the request is considered to be "approved."
Front-end profiles can also be viewed before the user is activated/validated. Should we change that behavior?
I have added a filter so that when requests are enabled, it is possible to bypass the manual approval process for some users, like if users are using a certain email domain that you know is trustworthy (like your school or organization).

Attachments (36)

8582.1.diff (47.9 KB) - added by dcavins 2 years ago.
Add request membership capability. First draft.
1-enable-site-requests.png (102.2 KB) - added by dcavins 2 years ago.
Enabling site requests
2-user-request-membership-form.png (99.2 KB) - added by dcavins 2 years ago.
Request form
3-user-completes-request-form.png (49.3 KB) - added by dcavins 2 years ago.
Form completion
3a-user-prevented-from-logging-in.png (23.5 KB) - added by dcavins 2 years ago.
User has a pending account, so can't log in yet.
4-site-admin-receives-email.png (18.0 KB) - added by dcavins 2 years ago.
The site admin gets an email about the request
4a-admin-receives-notification.png (57.0 KB) - added by dcavins 2 years ago.
Site admins also receive an on-site notification.
5-manage-signup-table.png (115.3 KB) - added by dcavins 2 years ago.
Manage signups table
6-manage-single-view.png (106.4 KB) - added by dcavins 2 years ago.
Checking a user's submitted info.
7-user-receives-activation-email.png (33.5 KB) - added by dcavins 2 years ago.
Once approved, user receives the activation email.
8-manage-signups-after-approval.png (114.3 KB) - added by dcavins 2 years ago.
After the approval email has been sent.
9-user-follows-activation-link.png (30.4 KB) - added by dcavins 2 years ago.
User follow the activation link.
10-user-activation-success.png (34.0 KB) - added by dcavins 2 years ago.
User successfully activates her account!
8582.2.add-links.diff (2.7 KB) - added by dcavins 2 years ago.
Add Request Membership links to WP Toolbar, meta widget, wp-login form.
8582.3.diff (59.9 KB) - added by dcavins 2 years ago.
New patch.
request-membership-links-wp-login.png (13.0 KB) - added by dcavins 2 years ago.
Link added to wp-login screen
request-membership-links-1.png (19.5 KB) - added by dcavins 2 years ago.
Links added to widget form.
manage-signups-new-column.png (74.6 KB) - added by dcavins 2 years ago.
new column on Manage Signups screen.
manage-signups-xprofile-modal.png (70.6 KB) - added by dcavins 2 years ago.
Modal for profile info on manage signups screen.
manage-signups-approval-screen.png (19.3 KB) - added by dcavins 2 years ago.
new language on "send approval email" screen
mail-dear-john.png (8.1 KB) - added by dcavins 2 years ago.
Sad rejection letter.
8582.4.patch (15.7 KB) - added by imath 2 years ago.
8582.5.patch (67.3 KB) - added by dcavins 2 years ago.
Updated patch including imath's changes and a few more improvements.
8582.6.patch (71.3 KB) - added by dcavins 2 years ago.
Updated patch.
8582.6-refreshed.patch (64.9 KB) - added by imath 2 years ago.
8582.7.patch (35.1 KB) - added by imath 2 years ago.
8582.8.patch (72.4 KB) - added by imath 2 years ago.
8582.9-just-diff.patch (11.6 KB) - added by dcavins 2 years ago.
Just the changes made after imath's .8 patch. It contains the necessary changes for multisite setups, so that the activation email is interrupted like it is on single site setups
8582.9-combined.patch (79.2 KB) - added by dcavins 2 years ago.
Complete patch with all changes up to now.
8582.10-just-diff.patch (9.7 KB) - added by dcavins 2 years ago.
Just the changes from the .9 patch.
8582.10-combined.patch (83.0 KB) - added by dcavins 2 years ago.
Combined change set.
85582.11.signups-changes.patch (6.6 KB) - added by dcavins 2 years ago.
Changes to BP Signups found by working with them. Coninues earlier work on signups class.
add-site-request-info.png (29.7 KB) - added by dcavins 2 years ago.
Example display of site request info.
8582.12-site-request-info.patch (8.0 KB) - added by dcavins 2 years ago.
In the multisite Manage Signups screen, display site request info in the profile info modal.
8582.12.combined.patch (84.6 KB) - added by dcavins 2 years ago.
Combined change set.
8582.12.recommandations.patch (10.1 KB) - added by imath 2 years ago.

Download all attachments as: .zip

Change History (71)

@dcavins
2 years ago

Add request membership capability. First draft.

#1 @dcavins
2 years ago

I would appreciate help testing the first patch. There are some things I know still need to be handled, like marking notifications as read when signups are approved or deleted. If you notice anything (in either Legacy or Nouveau) that seems off, please let me know. It is probably not necessary to do a line-by-line review of the patch yet. :) Thanks for your feedback!

I am attaching a series of images showing the basic steps in the process, for easy review.

Last edited 2 years ago by dcavins (previous) (diff)

@dcavins
2 years ago

Enabling site requests

@dcavins
2 years ago

Request form

@dcavins
2 years ago

Form completion

@dcavins
2 years ago

User has a pending account, so can't log in yet.

@dcavins
2 years ago

The site admin gets an email about the request

@dcavins
2 years ago

Site admins also receive an on-site notification.

@dcavins
2 years ago

Manage signups table

@dcavins
2 years ago

Checking a user's submitted info.

@dcavins
2 years ago

Once approved, user receives the activation email.

@dcavins
2 years ago

After the approval email has been sent.

@dcavins
2 years ago

User follow the activation link.

@dcavins
2 years ago

User successfully activates her account!

#2 @imath
2 years ago

Waou !! This looks really promising !! Thanks a lot for your work on this ticket, the patch and the screenshots. I’ll test the patch asap and will provide more feedbacks soon 👍

#3 follow-up: @imath
2 years ago

Here are my first feedbacks @dcavins. For now I haven't reviewed the patch in detail to focus on the feature's (needed imho) improvements.

Thanks a lot for this first pass about the feature. It's already very promising and it should work great when the registration process creates a User, but...

1) About the BuddyPress/WordPress signup process

There is only 1 case where a user is created once they submit the registration form: when WordPress is not multisite and when the BP_SIGNUPS_SKIP_USER_CREATION is not defined or false.

As a result, I strongly discourage you to use data from the wp_users table for this feature.

2) About the setting:

Would it be better to name the feature "site membership requests" instead of "network membership requests" if WordPress is not multisite or if BuddyPress is not network activated?

  • The checkbox should be readonly until the required signup option matches the need for disabling public registration.
  • We should probably include a link to where to turn public registration off.
  • This setting can't be 1 or 0 imho because of Multisite registration possibilities (account, account + blog).

3) What's the strategy to add the link to request a membership?

Should we include a link to the wp-login.php form at the minimum?

4) Testing the patch:

PS: On purpose (I knew doing so I'll get some errors 😆) I've set the BP_SIGNUPS_SKIP_USER_CREATION constant to true.

4.1) Once I submit the form I got a success message but also a notice error:

Undefined variable $item_id in /path-to/buddypress/src/bp-members/bp-members-membership-requests.php on line 119

You should probably use $signup->id instead.

4.2) If i go to the Manage signups screen, the request is listed but:

Warning: Attempt to read property "ID" on bool in /path-to/buddypress/src/bp-members/bp-members-notifications.php on line 85

That's because as I've explained above: the user wasn't created, because I've set the BP_SIGNUPS_SKIP_USER_CREATION constant to true.

I don't get the Extended link for the user requesting a site membership. See screenshot below:

https://cldup.com/Y1fEPCZIKA.jpg

If I click on the notification link, nothing happens unlike what the 6-manage-single-view.png shows. I stay on the Signup list. That's because of the BP_SIGNUPS_SKIP_USER_CREATION constant, but it would also be the case for Multisite configs. Using the Extended Profile is an interesting idea, but I believe we need more work to use a UI that is available for any WordPress/BuddyPress configs.

4.3) Possible improvements/questions :
  • Could we have like it's the case for pending comments a specific yellow background applied to the row?
  • What about a row action to reject with an email message the request?
  • When clicking on the Activate row action in this case, how is the requesting user informed their account has been activated?
  • The approve request row Action should lead to an adapted "Resend Activation Emails" screen:
    • page title = "Approve request(s)"
    • description = "You are about to approve the following request(s)"

5) About the admin email notice content

To learn more about the site, visit: site.url

What are we supposed to learn more, as an Admin I know my site, don't I? I'd remove this part from the email. This may only be interesting for multisite configs.

To view {{requesting-user.name}}'s profile, visit: profile.url

As on multisite or if BP_SIGNUPS_SKIP_USER_CREATION is true : the User is not created: this should fail (I wasn't able to test emails on my config). It should be the link to open the Admin UI made available for any WordPress/BuddyPress configs.

Conclusion:

As I've said it's very promising and you already did some great work about it. But I believe we need some more work to take in account the 2 other signup processes you haven't covered so far 😁

#4 in reply to: ↑ 3 @dcavins
2 years ago

Replying to imath:
Thanks for your feedback, imath!
I have a few questions and/or responses:

  • This setting can't be 1 or 0 imho because of Multisite registration possibilities (account, account + blog).

I'm not sure what you mean. Can you explain why enabling request or not would need more than on/off?

3) What's the strategy to add the link to request a membership?

Should we include a link to the wp-login.php form at the minimum?

I've added a link to the BP login form, but sure, it seems like it should be added to the wp-login form as well.

Using the Extended Profile is an interesting idea, but I believe we need more work to use a UI that is available for any WordPress/BuddyPress configs.

Sure. There may be a way to hotwire the extended view for signup IDs. I'll look into it.

  • What about a row action to reject with an email message the request?

I agree that we should probably send a "rejected" email. Poor requester. :)

  • When clicking on the Activate row action in this case, how is the requesting user informed their account has been activated?

They get the welcome email.

Thanks again for taking a look at this!

@dcavins
2 years ago

Add Request Membership links to WP Toolbar, meta widget, wp-login form.

#5 @imath
2 years ago

You're welcome 😉.

About:

I'm not sure what you mean. Can you explain why enabling request or not would need more than on/off?

Correct me if I misunderstood: to turn on site membership requests. You need to disallow public registration. On a single site config, the WP option 'users_can_register' can be 1 or 0 so I agree with you.

But on multisite, the corresponding WP site meta 'registration' can be 'all', 'blog', 'user' or 'none', so what the admin needs to select to enjoy the site membership requests feature ? 'blog' or 'none' ?

How would we handle the case where only user account can be requested?
How would we handle the case where both user account and site can be requested?

(there's a chance I'm overthinking it! 😅)

Last edited 2 years ago by imath (previous) (diff)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


2 years ago

#7 @dcavins
2 years ago

Here's an updated version of the patch that makes a few changes. The biggest difference is that instead of trying to use the user pages (in WP-Admin), any submitted extended profile data is available in the "Manage Signups" screen, which relies on the signup data only, and I've removed any code that refers to users. Other changes:

  • Add links to the request membership form to the widget login form, wp-login, and the WP toolbar.
  • Send a rejection email to rejected users. :,(
  • Change the language on the manage signups > resend email screen (rebranded to "send approval emails").

Images and a fresh patch to follow.

@dcavins
2 years ago

New patch.

@dcavins
2 years ago

Link added to wp-login screen

@dcavins
2 years ago

Links added to widget form.

@dcavins
2 years ago

new column on Manage Signups screen.

@dcavins
2 years ago

Modal for profile info on manage signups screen.

@dcavins
2 years ago

new language on "send approval email" screen

@dcavins
2 years ago

Sad rejection letter.

#8 @imath
2 years ago

Really nice! Thanks a lot for your work on these improvements! I'll test the patch asap.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


2 years ago

@imath
2 years ago

#10 follow-up: @imath
2 years ago

Hi @dcavins

I've tested the patch, and was a bit surprised at the beginning as submitting a membership request was sending an activation email. Then I understood checking your previous patch that one file was missing. So I've used 8582.1.diff to include the missing bp-members-membership-requests.php file into 8582.4.patch to have it work the way it should. You should probably check again my edits about this file 😆. 8582.4.patch also includes some recommandation (eg: escaping some outputs, or displaying a message when there are no profile field to display into the modal).

I have some remarks/questions 😁.

  • I guess the purpose of having a separate bp-members-membership-requests.php is to only include it if Membership requests are allowed, so I've edited this part in the 8582.4 patch. But I see a lot of functions that should be moved into this file... (eg: all the ones that are inside src/bp-members/bp-members-filters.php).
  • Why do we need bp_is_active( 'members', 'invitations' ) for site membership requests? It seems weird to me.
  • Is the Approved column necessary into the WP List Table? I don't see the benefit of it.
  • The "Manage signups" WP Admin Menu item should probably be renamed "Manage Pending members".

Otherwise, thanks a lot for your great progress about the ticket, we're getting closer to the finish line 🏁.

On a side note and to follow up with our latest dev-chat: I've checked how WordPress uses the inline-edit feature and I don't like it. I believe we can do things better now we have the BP REST API and modern JavaScript. I'll explore this in another ticket.

#11 in reply to: ↑ 10 @dcavins
2 years ago

Replying to imath:
That's strange about the patch. It sure looks like new file src/bp-members/bp-members-membership-requests.php is included in the attached https://buddypress.trac.wordpress.org/attachment/ticket/8582/8582.3.diff. Maybe when you applied the patch, the new file wasn't created because of permissions or similar?

Regarding file organization, I am in favor or moving filters and actions to the main file bp-members-membership-requests.php. Putting filters in a filters file is how BP is often organized, so I respected that, but personally prefer having files organized by content, not part of speech.

I think the Approved column is useful (it's a renaming of an existing signup column, date activation email sent) because some pending memberships will have been "approved" but not activated by the end user yet. The column tells you at a glance when the approval occurred or if it hasn't yet. You could also use it to sort the "not yet approved" requests up to the top (I will enable sorting on it).

The $64,000 question: What should we do with meta for the 10.0 release? Leave it on the "activate" and "approve" screens? Use a modal, but maybe move the access link to the "actions" cell? I think it would be great to add an inline viewer/editor, but let's not let it hold up anything--it can be a nice improvement later.

Thanks!

#12 @dcavins
2 years ago

I'm about to upload a new version of the patch with the following changes:

  • Incorporate @imath's changes (though I had to manually merge changes in bp-members-membership-requests.php so may have missed a new escape addition there).
  • Support bp_is_active( 'members', 'membership_requests' ) so that the functionality can be disabled/hidden via code if desired.
  • Move filters from members-filters into bp-members-membership-requests.php and remove several bp_get_membership_requests_required() checks from those functions since that file is only included when membership requests are enabled.
  • Filter the "Manage Signups" menu item label in WP Admin > Users when requests are enabled.

Thanks!

@dcavins
2 years ago

Updated patch including imath's changes and a few more improvements.

#13 @dcavins
2 years ago

Another small update to delete associated notifications when a signup is approved, activated or deleted.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


2 years ago

@dcavins
2 years ago

Updated patch.

#15 @dcavins
2 years ago

I've uploaded a new patch that contains the previous updates plus these changes:

  • Manage Pending Memberships screen: move profile info view link into row actions.
  • Manage Pending Memberships screen: Add request-specific help tab content.
  • Update default logic for BP_Signup->count_sent to treat no meta set like an old-style signup.
  • Add email installation upgrade routine.
  • Disable settings checkbox is "anyone can register" is true.

Thanks for your help with testing!

@imath
2 years ago

#16 @imath
2 years ago

Thanks again for the great work you've being doing on this ticket @dcavins. I've tested the patch and it works pretty fine 👏

I've refeshed it (see 8582.6-refreshed.patch) and made sure to remove the src/bp-members/bp-members-membership-requests.php.rej that was in your version and confused me a bit at the beginning.

Once 8582.6-refreshed.patch is applied, you can apply 8582.7.patch. This second patch contains some improvement suggestions:

  • Add more escaping functions
  • Fix missing textdomain
  • Add some code standards/format/inline documentation improvements
  • Limit code duplication into the WP List Tables (see bp_members_admin_preview_signup_profile_info() & bp_members_admin_format_xprofile_field_for_display())

I've also added 2 JavaScript files to make sure the Signup's profile info modal is more inline with the Hello one.

If these are fine with you, the last step (unless you find other improvements) would be to give it a last check on a multisite config as I haven't done so.

I can see the finish line!

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


2 years ago

@imath
2 years ago

#18 @imath
2 years ago

As discussed yesterday during our development meeting. 8.patch = 6-refreshed.patch + 7.patch.

I've tested on multisite and found 2 annoying issues:

  1. having the WP registration settings set to "Logged in users may register new sites"
    1. It's possible to request a blog directly from the membership request form, should we allow this ?
    2. Once the form is submitted, the user receives the activation link and can activate their account. We don't want this 😉
  2. Having the WP registration settings set to "Registration is disabled": when submitting the form, the request membership page is displayed again and empty and it's possible to resubmit the form refreshing the page. I guess there's a redirection missing in action 😉. Unlike what I've thought there's no fatal error during the process.

FYI, I've tested again on a regular WordPress site, it works as expected 👌

#19 @dcavins
2 years ago

I'm attaching two files:

  • 8582.9-just-diff.patch is just the changes made after imath's .8 patch. It contains the necessary changes for multisite setups, so that the activation email is interrupted like it is on single site setups. I've tested all four WPMU registration allowance options, but would love for other testers to work through each scenario, too.
  • 8582.9-combined.patch is a complete patch that you should be able to apply to a fresh branch and have all of the requests functionality.

Specific questions or thoughts:
I've added a WPMU user meta filter to mirror changes made in the BP_Signups class. I've put it in bp-core-filters.php near other wpmu filters. Is that the right place for the filter?
The "close" button in the thickbox modal appears outside the modal, to the right. Is that the correct location? It's a little hard to see over the dark scrim.

Thanks again for your feedback!

@dcavins
2 years ago

Just the changes made after imath's .8 patch. It contains the necessary changes for multisite setups, so that the activation email is interrupted like it is on single site setups

@dcavins
2 years ago

Complete patch with all changes up to now.

#20 follow-up: @imath
2 years ago

  • Keywords needs-refresh added; has-patch needs-testing removed

Hi @dcavins thanks for your improvements about Multisite issues.

I've tested on a regular site first: everything works as expected ✅

I've tested all registration options and it's almost working as expected. There are still things to fix imho. ❌

1/ Registration is disabled

It works as expected, except for the facts:

  1. the user receives a WordPress generated message instead of the BuddyPress one. See capture below:

https://cldup.com/vhgk2kPTY8.png

It's pretty annoying because, it looks like this message is originally for the SuperAdmin and more annoying, when the user clicks on the link, the password he chose during signup is reset by WordPress, see capture below:

https://cldup.com/s6lxOgYetE.png

  1. The new_member activity is not generated.

2/ Logged in users may register new sites

  1. We also have the above annoying WordPress activation process in place instead of ours.
  2. The new_member activity is not generated, as well.
  3. It's possible to request a new site, although we're not yet logged in, see below capture:

https://cldup.com/WB81991gze.png

  1. As the SuperAdmin when reviewing the request, there's an information about the fact the user already received an approval request, but it's not the case. See screenshots below:

The Pending accounts list screen
https://cldup.com/ywVL_3OMfN.png

The confirmation screen
https://cldup.com/C-2onYLy9X.png

The other 2 WP registration options work as expected: the site membership feature does not interfere with the regular signup process.

Could you look at these issues? Thanks in advance 😍

#21 @imath
2 years ago

Oh and about your question:

The "close" button in the thickbox modal appears outside the modal, to the right. Is that the correct location? It's a little hard to see over the dark scrim.

It's the way it is for the Hello BuddyPress screen as well as the "more details" Plugin's modal. No worries 👌

#22 in reply to: ↑ 20 @dcavins
2 years ago

Replying to imath:

Thanks for your message, imath. It seems that the thing that's annoying you is an underlying issue in BP that all boils down to one fixable problem: From the WP multisite "Manage Signups" screen, when you choose the "email" action, the default WP MS email is sent rather than the BP version. I'll work to change that behavior.

Here are some general notes (that I made for myself) that I think will help clear up your other questions:

Multisite registration
option : bp_get_signup_allowed() : bp_core_get_root_option( 'registration' )
1 - Registration is disabled : false : 'none'

  • No access to registration form
  • + Membership requests allows access to registration form (becomes case #2 with approval).

2 - User accounts may be registered : true : 'user'

  • Access to registration form
  • + Membership requests are not enabled and don't change any behaviors.

3 - Logged in users may register new sites : false : 'blog'

  • No access to registration form
  • Sites are listed at /sites/ if "site tracking" is enabled. New site creation happens at sites/create and is available to all registered users.
  • + Membership requests allows access to registration form, which includes the "I want a blog" section (becomes case #4 with approval step).
  • + Site is not created when request is submitted. (Good behavior.)
  • + Flow: Request submitted. Admin is notified. Admin approves. User gets WPMU email with activation language. (This is the same email that is sent when you select "Email" if option 4 is set, and what needs to be changed)

4 - Both sites and user accounts can be registered : true : 'all'

  • Access to registration form
  • Registration form includes "I want a blog" section.
  • + Membership requests are not enabled and don't change any behaviors.

The other thing you're seeing ("Resend approval" when approval hasn't been sent yet) is a result of missing meta at signup. I fixed the "registration is disabled" case via the WPMU meta filter I added in the recent patch. That issue was that the WPMU default functions don't add the date_sent and count_sent meta we need to know that nothing has been sent. However, apparently the "user + blog" signup path uses a different filter, ha ha, because of course it does.

#23 @dcavins
2 years ago

Here are changes that fix several issues with the multisite setup:

  • 8582.10-just-diff.patch contain just the changes since the .9 patch. These include:
    • BP_Signup: Fixes to the signups class to correct an error introduced by my recent Signups changes (unsetting the meta array)--this was causing the generic WPMU email to be sent instead of the BP activation emails on multisite.
    • BP_Signup: Add logic that determines whether to send the MS user or blog activation email, depending on whether the signup contains domain or path info.
    • Add logic to bp_core_activation_signup_blog_notification() and bp_core_activation_signup_user_notification() so that the interruption does not fire if the admin is approving or resending the approval email.
    • Make sure that basic "sent" meta is added on the signup_site_meta hook in addition to the signup_user_meta in multisite.

I've also included a combined patch that has everything. I'll also make up a patch with just changes to Signups that I think we can commit anytime, to follow up on my earlier BP_Signups changes.

Version 0, edited 2 years ago by dcavins (next)

@dcavins
2 years ago

Just the changes from the .9 patch.

@dcavins
2 years ago

Combined change set.

@dcavins
2 years ago

Changes to BP Signups found by working with them. Coninues earlier work on signups class.

#24 @dcavins
2 years ago

In the multisite case, I wonder if it would be helpful to add some extra explanatory text under the requests toggle because the registration options + requests are not clear. Maybe something like:

With a WP multisite setup, to require membership requests for new signups, choose one of the following two options from the Network Settings > Registration Settings pane:
To allow the submission of membership requests but not allow site creation requests, select "Registration is disabled".
To allow the submission of membership requests and to allow new sites to be created by your users, choose "Logged in users may register new sites"
The other two options, "User accounts may be registered" and "Both sites and user accounts can be registered," are open in nature and membership requests will not be enabled if one of those options is selected.

@dcavins
2 years ago

Example display of site request info.

@dcavins
2 years ago

In the multisite Manage Signups screen, display site request info in the profile info modal.

@dcavins
2 years ago

Combined change set.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


2 years ago

#26 @imath
2 years ago

  • Keywords commit added; needs-refresh removed

Hi @dcavins, let's have it in! Thanks again for your great work on this feature. 8582.12.recommandations.patch is simply containing some code formatting recommandations. I've diffed from 8582.12.combined.patch.

I've run some new tests, everything works as expected ✅

This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.


2 years ago

#28 @dcavins
2 years ago

In 13166:

Introduce bp_get_membership_requests_required().

Introduce a new function to determine if membership
requests are enabled and add the toggle to the admin
form at BuddyPress Settings > Options.

See #8582.

#29 @dcavins
2 years ago

In 13167:

Add key membership request functionality.

When membership requests are active, interrupt the
activation process by not sending the activation mail
upon submission of the registration form. This allows the
site admin an opportunity to look over the request and
send the activation email manually.

See #8582.

#30 @dcavins
2 years ago

In 13168:

Add membership request-related emails and notifications.

Add 'members-membership-request' email and
'membership_request_submitted' notification
which is sent to site admins when a new request
is submitted. Also add
'members-membership-request-rejected' email
which is sent to the requester when denied.

See #8582.

t

#31 @dcavins
2 years ago

In 13169:

Manage Signups Screen: Change labels and behavior for requests.

Change many labels in the WP Admin Signups Screen
to reflect the membership requests capability when enabled.

Add new "Profile Info" action link to User List Tables
so that the site admin can see submitted extended profile
info and any blog requests.

See #8582.

#32 @dcavins
2 years ago

In 13170:

Membership Requests: Change labels on register page.

We are using the standard "register" form to collect
membership requests, so we need to change the labels
in many cases to avoid confusion. Also ensure that users
can access the registration page when membership
requests are enabled.

See #8582.

#33 @dcavins
2 years ago

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

In 13171:

Membership Requests: Add links to signup form.

Add links to the signup form in the WP sidebar,
on the login form and in the WP toolbar.

Fixes #8582.

#34 @dcavins
2 years ago

In 13172:

Membership Requests: Invitation interaction

If a user makes a registration request and is also
an invitee to the site, immediately approve the request.

See #8582.

#35 @imath
2 years ago

In 13173:

Improve the callback used to output the membership request setting

  • add missing buddypress text domain for l10n functions.
  • make sure the specific multisite explanations about the feature are rightly located into this callback instead of the site invitations setting one.

See #8582

Note: See TracTickets for help on using tickets.