Hi Nik,
We are reviewing your previous reply and the issue with self notification. I am expecting a final publish next week.The reason we haven’t published BuddyBlog group yet is the complexity. With too many options, there comes huge complexity and that has been one of the reason to hold back.
We are still not sure how we handle this as we do need settings at admin level as well as group level.We will be auditing BuddyBlog groups this week and I will push the update by early next week.
Thank you
BrajeshHi Brajesh
I can understand that to offer options to allow/disallow notifications dependent on user permissions, especially depending on whether or not group admins are allowed to change the various options could get very complicated!
Fortunately in my case at least, group admins are not allowed to change any of the settings ie. ALL posts require their approval (except for their own) and notifications should always be sent UNLESS it’s a post by the group admin themselves.
The fact that the code provided by Ravi doesn’t prevent the latter from happening for group posts is causing us major problems, since group admins can’t understand why they receive not even just one, but TWO emails (one as group admin, one as the author) for a post they’ve made themselves and is already published.
Unfortunately, the site is about to go live this week so if there isn’t any way of overriding this feature, the only other option I can think of is to edit the source code somehow myself, which is obviously not ideal but I don’t see any other alternative at this stage… and will definitely be keeping an eye out for any further updates as/when you have them available.
Regards
NikHi Nik,
Thank you for the reply and sharing the details.
When are you going live this week? I can try to release it before that.Thank you
BrajeshHi Brajesh
That’s so very kind of you. We’re hoping to go live Wednesday or Thursday at the latest, which I do appreciate doesn’t leave much time so please don’t worry if it’s just not possible… although would be wonderful if it is (even if it’s only a temporary/interim fix ;-))
With many thanks again
NikHi Nik,
Thank you for the reply.
Please upgrade to 1.0.0-rc7.This update will disable self notification to group admin/site admin for post approval, rejection, submission.
If in a group, there are 4 group admins and one of them submits the post, the other 3 will still get a submission notification.
Do you want to disable that too?
PS:- The code from Ravi is no longer needed for site admin/group admin notification prevention.
Regards
BrajeshOh 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 Nik,
Thank you for the reply.
I am glad I was able to spend sometime and have a fix.Please do share the results of your testing. For the multiple group admins, if it not a big hassle, Please allow me to put the fix in next update(It will be just 1 line change but we are already on RC7 so trying to avoid another 1 line update release).
All the best with your launch!
Regards
BrajeshHi 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 sentPosting 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 meGroup 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.
NikHi Nik,
Thank you for the feedback.My changes are limited to Group Blog and have no affect on how BuddyBlog Pro works.
I haven’t updated BuddyBlog and the last changes were limited to Group posts only.1. Admin notifications.
Sorry the line should have been thisif ( get_current_user_id() == $post->post_author && is_super_admin() ) { return; }
not
if ( get_current_user_id() == $post->post_author ) { return; }
An update will be available today for this.
2. Group admins still receive the author notification:- That is correct. We do’t have UI to disable and I can’t disable it for specific use case as there is a possibility group admins might not have the ability to publish for some of the setup.
I put a filter there yesterday ‘bblpro_groups_post_submission_notify_author’You can use it like.
// disables author notification for group admin. add_filter( 'bblpro_groups_post_submission_notify_author', function ( $notify, $author, $post, $group_id, $form_id ) { if ( groups_is_user_admin( $author->ID, $group_id ) ) { $notify = false; } return $notify; }, 10, 5 );
3. Can you please help me understand this
Those posting in group with admin or editor permissions are handled in the same way as “regular” group members (ie. non group admins)
Should we treat them differently?
I am not using roles as I the purpose of BuddyBlog pro/Group blog is for community posts and not editorial content of the site.Regards
Brajesh
You must be logged in to reply to this topic.