Opened 10 years ago
Closed 10 years ago
#6524 closed enhancement (fixed)
Add filter point before group membership requests are saved
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 2.4 | Priority: | low |
Severity: | minor | Version: | 1.0 |
Component: | Groups | Keywords: | needs-patch |
Cc: | david.cavins@… |
Description
We currently don't offer a way to prevent membership requests from being saved on a per-request basis. Say, for example, you want to add a required extended profile field, or you want to require that the "comments" field be completed before accepting the membership.
The attached patch adds a filter that fires immediately before the member is saved so that plugins can stop the process if necessary.
Please let me know if there's a smarter way to accomplish this.
Attachments (2)
Change History (10)
#3
@
10 years ago
Thanks for your comments, r-a-y!
I think that your pre-save bail condition makes perfect sense in BP_Groups_Member::save()
, since it would be applicable to every group membership case.
I do wonder, though, about how easy it'd be for a beginner BP-er to find it and see how it could be used to stop a request from being created (like knowing how to identify membership requests vs invitations at the groups_member_before_save
filter and that emptying the user_id
would then torpedo the save).
Maybe there's value to adding both approaches--the covers-every-case bail condition and the really-obviously-named filter. :)
#4
@
10 years ago
I do wonder, though, about how easy it'd be for a beginner BP-er to find it and see how it could be used to stop a request from being created (like knowing how to identify membership requests vs invitations at the groups_member_before_save filter and that emptying the user_id would then torpedo the save).
For sure! Let's do both.
I think we should add the bail condition to
BP_Groups_Member::save()
.Then you could manipulate the request object on the
'groups_member_before_save'
hook. Seebp_groups_member.patch
for what I have in mind.