Hi Brajesh

Thank you so much. Those filters should allow me to achieve everything I need to achieve (and hopefully will be helpful to others too), so really appreciate it.

I will of course test and let you know if I run into any queries 😉

Regards
Nik

Hi Brajesh

As always, thank you for your prompt reply and I do understand that these changes are for BuddyBlog Groups only.

1. Thank you for the correction and that makes sense.

2. I did think I caught sight of the new filter but hadn’t had time to test it myself. That looks perfect and will work for my purposes.

3. Sorry, I realised I didn’t explain my comment about admin and/or editor permissions very well and/or what I was hoping to achieve so to clarify –

The site has a couple of users with the role of “editor”, who are allowed to publish/edit any/all posts throughout the site. Obviously, they can do this in the backend, but also using the BuddyBlog Groups interface from within a group, even if they are not a member of that group. In order to allow them to publish in a group (without requiring approval), I have used the bblpro_default_post_status_for_user and set it to “publish” for those with the role of editor.

This works well for both BuddyBlog Pro and BuddyBlog Groups insofar as their posts are published immediately, and by using this code…

/**
 * Skip notification on post submit
 *
 * @param null    $skip_notify  Need to notify or not.
 * @param WP_Post $post         Post object.
 * @param int     $form_id      Form id.
 *
 * @return mixed
 */
function buddydev_skip_post_submit_notification( $skip_notify, $post, $form_id ) {

	if ( 'publish' === bblpro_get_default_post_status_for_user( get_current_user_id(), $form_id, $post->ID ) ) {
		$skip_notify = true;
	}

	return $skip_notify;
}
add_filter( 'bblpro_pre_handle_post_submission_admin_notification', 'buddydev_skip_post_submit_notification', 10, 3 ); 
add_filter( 'bblpro_pre_handle_post_submission_author_notification', 'buddydev_skip_post_submit_notification', 10, 3 );

I can stop the notifications for personal posts however, they’re still getting sent out for group posts.

As you mention there is now a filter – bblpro_groups_post_submission_notify_author – I can use this to prevent the author notification that gets sent out when an editor adds a post. Now I just need to find a way to prevent the admin and group admin notifications from getting sent out. If there were similar filters for these, within BuddyBlog Groups, that would be very helpful.

Regards
Nik

Hi Brajesh

Having installed the update, I’ve been doing some testing with results as follows –

Note: I am focusing on the emails that get sent out when a post is first submitted’

Personal/members posts (ie. created from the user profile)
Both site admin and author notifications are still sent out even if the bblpro_get_default_post_status_for_user is set to “publish”. Note: this doesn’t really surprise me since it’s only BuddyBlog Groups that has been updated, but means that currently at least, Ravi’s code is still needed for this particular scenario.

Group posts (ie. created from group profile)
Posting as group admin – admin and group admin notification do not get sent out (which is correct), but author notification is still sent

Posting as member (not admin) – group admin and author notifications get sent out (which is correct), but for some reason, site admin notification does not! (I double-checked this one by downgrading to RC 6 and the site admin notification does then get sent out, so something about RC 7 is definitely affecting this.)

Posting with the role of admin or editor – group admin and author notifications still get sent out (and I suspect the site admin notification would too, if it was working in scenario above).

Summary:
Personal posts – still need a way to handle these, although Ravi’s code works well for me

Group posts –

1) For some reason, site admin notification is no longer getting sent out under (any?) circumstances
2) Group Admins still receive the author notification
3) Those posting in group with admin or editor permissions are handled in the same way as “regular” group members (ie. non group admins)

Notes:
Looking at the new code, I think I can maybe see why the site admin notifications are no longer getting sent out since this is based on whether the author of the post is the current user and presumably this will always return true?

Even where it’s working, assuming I am understanding correctly then the rest of the new code seems to use the logic of whether a notification is about to be sent to the author of the post (eg. no point sending a group admin notification if the person posting in group admin) however… I do wonder if checking the permissions of the poster for that post (ie. bblpro_get_default_post_status_for_user = publish) would be a more reliable indicator of which notification(s) should be sent out. (Note: whilst this would certainly work better in my particular use case, I admit, I haven’t thought through whether it would necessarily work in all possible scenarios ;-))

I do hope this makes some sense and is helpful. I certainly don’t expect an immediate fix and if it’s easier to wait until you’re ready for the next full release, that’s not a problem but if you’d like me to test anything further in the meantime, please don’t hesitate to let me know.

With many thanks for your time as always.
Nik

Oh wow Brajesh that’s amazing! I didn’t dare to hope you could get it done in time 😉

I think ideally if one group admin submits a post, the other group admins really don’t need to know (the point being that if someone has the power to publish their own posts, there’s no need for someone else to be notified and/or in order to check it)… but no rush to fix that unless it’s easy to do, as we can certainly live with it as it is for now.

I’ll do some testing over the next 24 hours but fingers crossed, that all sounds very promising and I can’t tell you how much I appreciate it. Thank you so much and I’ll let you know how I get on.

Nik

Hi Brajesh

Thank you again and yes… I know that works just great for group posts.

It was actually how to reject a user/member submitted post that caught me out, since as far as I am aware, that can only be done in the backend and it was me who changed the status to “rejected” and then saved/published the post, rather than keeping it as “pending”!

Anyway not a problem now I know… and will warn others 😉

Regards
Nik