Skip to:
Content
Pages
Categories
Search
Top
Bottom

Allowing Group Email Subscription access only to a whitelist

  • Avatar of Boone Gorges
    Boone Gorges
    Keymaster

    @boonebgorges

    As promised here http://buddypress.org/community/groups/buddypress-group-email-subscription/forum/topic/stableish-release-of-buddypress-group-email-subscription-with-digests/, I have cobbled together an ugly but functional version of the plugin that allows you, as the admin, to restrict access to the plugin’s functionality to a defined whitelist. I’m going to use this on my site for some beta testing before a sitewide rollout, but I can imagine a lot of other uses for it.

    Instead of uploading a file, I’m going to give you the instructions on how to set it up, as it’s important that you understand what you’re doing (this is not yet a truly supported feature).

    1) In bp-activity-subscription.php, define a variable called $ass_whitelist. Do this outside of any function, ideally right before the function activitysub_load_buddypress. Here’s an example:
    $ass_whitelist = array( 2,6,10 )
    This means that only members 2, 6, and 10 will be able to use the plugin.

    2) In bp-activity-subscription-functions.php, add the following two functions to the top of the plugin file:
    function ass_check_whitelist() {
    global $ass_whitelist, $current_user;

    if ( empty( $ass_whitelist ) || in_array( $current_user->ID, $ass_whitelist ) ) {
    add_action( 'wp', 'ass_update_group_subscribe_settings', 4 );
    add_action ( 'bp_group_header_meta', 'ass_group_subscribe_button' );
    add_action ( 'bp_directory_groups_actions', 'ass_group_subscribe_button' );
    //add_action ( 'bp_directory_groups_item', 'ass_group_subscribe_button' ); //useful to put in different location with css abs pos
    add_action( 'bp_group_members_list_item_action', 'ass_show_subscription_status_in_member_list', 100 );
    add_action( 'bp_notification_settings', 'ass_group_subscription_notification_settings' );
    } else {
    add_action( 'wp_head', 'ass_hide_email_options' );
    }
    }
    add_action( 'wp', 'ass_check_whitelist', 1 );

    function ass_hide_email_options() {
    ?>

    li#nav-notifications-personal-li { display: none !important; }

    <?php
    }

    The first function checks against the whitelist before activating the relevant hooks. The second one is an ugly hack having to do with the fact that BP Group Extensions are hard to deregister.

    3) Look through bp-activity-subscription-functions.php to find all the add_action references in the function ass_check_whitelist above, and comment them out. For example, you should find the other place in the file where it says
    add_action( 'wp', 'ass_update_group_subscribe_settings', 4 );
    and turn it into
    // add_action( 'wp', 'ass_update_group_subscribe_settings', 4 );
    This last step is very important, or the whitelist will do nothing – everyone will be able to access the plugin’s functionality.

    Let me know in this thread if you have any problems.

    (heads up @hnla)

Viewing 5 replies - 1 through 5 (of 5 total)
  • Avatar of Hugo
    Hugo
    Moderator

    @hnla

    @boonebgorges great stuff I’ll run a trial on the production site using that in the morning and see how it performs. Clearly I was living in a delusional coding delirium thinking I could get away with my original 6 lines of code :lol:

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    A very minor issue, but it looks as though users who may already have had options set before this whitelist hack is enabled will still have access to the functionality, although it looks like they cannot actually update/change options and not sure if they would be emailed digests.

    Re “Ugly hack” I have to concur :) mainly in due to the fact that that function ass_hide_email_options() is oh so very bad :angry:
    I’ll look further as there is probably a simple fix but look at how that ruleset is being injected to the DOM. As it stands this can’t be run on a production site really.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    Hmm was getting some odd disparages between source views and FB views.

    Updated your ass_hide_emai_function() to:


    function ass_hide_email_options() {
    <style type="text/css">
    /*<![CDATA[*/
    .group-subscription-div,
    .ass-topic-subscribe, /*this elements parent td needs a class! css does not do xpath*/
    li#nav-notifications-personal-li { display: none !important; }
    /*]]>*/
    </style>

    }

    This should remove the stray elements I was seeing for a non white listed user and style tags keeps browsers and the dom happy :)

    Avatar of Boone Gorges
    Boone Gorges
    Keymaster

    @boonebgorges

    @hnla. I have been using this setup on a production site for a coulple days in order to beta test and it’s been working ok for me. You are right that ass_hide_email_options is a terrible, terrible thing to do, but that’s not because it traverses the DOM incorrectly (though maybe it does). The problem is that it should never render that link to begin with. It’s just a little complicated to actually make that work right.

    As for your first question, I think that the only problem would arise if users had previously had subscribed to group notifications *via this plugin*, then the plugin was deactivated and reactivated with the aforementioned modifications. Then they would continue to receive notifications as per their previous settings, but the would not have access to the UI to change them.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    Agreed to the second part it was due to previous user setup and although they could see aspects of the plugin rendered it didn’t look like they could actually effect any further changes to it – this is a non issue as there wouldn’t have been previous usesrs set up on the production site.

    My traversing comment was more to do with the fact that I would have removed the TD rather than it’s child elements leaving the td rendered and empty.

    My only real gripe and real reason for posting the change (the actual additional selector sets were due to my issue with seeing elements for a user already configured on test site – it was simply playing safe) was the lack of style tags this will cause issues and I would never render mal -formed code in this manner on a production site, it does cause issues but they may not be obviously apparent, Firebug definitely didn’t know what to do with cdata there and was telling me that it was appearing in the body!

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.