Skip to:
Content
Pages
Categories
Search
Top
Bottom

Search Results for 'Hide Admin'

Viewing 25 results - 851 through 875 (of 915 total)
  • Author
    Search Results
  • #8511
    ousep
    Participant

    I’m trying out bp trunk, on a wp trunk install. In particular, the activity section.

    Is there a way to specify settings on activity? Apart from via the theme files, ie.

    For instance, can an admin specify how deep nested replies can go? I’ve tried it out, and after the 10th one or so, it stops making sense for it to continue. In narrower screens, that would stop at 5 or 6, I guess.

    Additionally, nesting could be disabled completely, as in the comment settings.

    Disable replies on certain activity types – Not every activity needs a discussion. Instead of offering just “Disable activity stream commenting on blog and forum posts?”, split it up and offer this on every activity type, separately.

    Limit visible replies to an activity item to the latest (or the earliest) X number, a la facebook. On an active site, replies to activity could take up several scrolls worth of screen space. And if a visitor isn’t interested in that particular topic, the site loses that visitor. The rest of the replies could be shown and re-hidden on demand.

    Public replies to activity items: In many cases, updates would be taking the place of blogs, and should replies be limited to only registered users? The onus for moderating public replies can lie with either the the activity author, or the site admins.

    Does akismet work on activity replies?

    Hide certain activity types from showing on the activity page. Offer everything… let the site admins decide on what they want on the activity streams.

    Some of this might already be possible, but if these could be offered in the admin panel under Buddypress, it would make things much easier.

    21cdb
    Participant

    Great work! I haven’t had the time for a detailed test, but i have some short feadback for the beginning:

    1. Everything works fine and seems logical. Thats great. There could be some front-end twaeks, but i will come back later next week with some more detailed ideas and mockups.

    2. From our experience it is great to have advanced edit functions but hide them in a second row from the avarage user (like the wordpress backend editor does). For a wiki article the user (students) should focus on the content instead of any fancy formating. Basic options could be a select-box for h1, h2, h3 (this is important and must be easy accessible, because it will build the toc and people should get used to it) bold, italic, url link, unordered list, and numberd list. Everything else could go in a second or third row which appears if you click some “advanced options” button.

    3. (future release) A searchable wiki directory page with all public pages.

    4. (future release) “Suggest a wiki page” button so that non admin-members could ask the admin to create a new wiki page for them.

    5. (future release) non-admin wiki page creation

    w101
    Participant

    I need to find a permanent solution that would allow me to HIDE user IP addresses and email in the comments, and the backend admin. Really everywhere.

    I can manually edit pluggable.php and comment-template.php in the includes folder, but each time I update they invariably are overwritten and I have to do it all over again.

    Does anyone know of a plugin for this or have another solution?

    Thanks!

    I’m trying to limit the private information that is being displayed to anyone that happens to create a blog.

    #61121
    Bowe
    Participant

    I don’t have a solution for all your problems but assigning different “user” types to your site is easy:

    – Create a xprofile field in your BuddyPress admin. For example: What kind of user are you:

    a. Swimmer

    b. Skater

    c. Surfer

    – Install the BP Member filter plugin: https://buddypress.org/forums/topic/bp-member-filter

    – Users can now filter members on the member directory page to find certain usertypes

    The only thing you might want to look into is to show/hide specific xprofile fields for different groups. That’s more advanced and requires some new code to be written by someone ;)

    Good luck!

    edit: Maybe if you combine both tips from Boris and me you just got your solution ;)

    ps: I’m interested in the jquery profile fields stuff as well.. sounds handy!

    r-a-y
    Keymaster

    The way I see it, you have a couple of options:

    1) Continue using your external bbPress setup for open, public discussions (similar to bp.org/forums), while hiding all group forums and group forum related discussions from your external bbPress install.

    BP group forum discussions will now be using the new integrated forums in BP 1.1 only for group discussions. And you can retain all your external bbPress posts!

    This essentially means you’ll have two forums.

    2) Move everything over to the integrated BuddyPress forums (not something you want to do I’m guessing).

    3) Move everything over to the external install of bbPress (requires BP core hacking, doable, but more work).

    Option 1 is probably the most viable.

    Here’s how to do it:

    Step #1 (optional, depending on where you installed your external version of bbPress)

    By default, BP group forums can be accessed at:

    hxxp://example.com/forums/

    If your external bbPress is also installed in /forums/, you’ll want to rename BP’s forums slug to something else.

    You can do this by adding the following in your wp-config.php or bp-custom.php:

    define( 'BP_FORUMS_SLUG', 'group-forums' );

    In the example above, your BP forums can now be accessed at hxxp://example.com/group-forums/

    Step #2

    In your external bbPress install, make sure all your group forums are under a forum category.

    If you don’t have a forum category specifically for your group forums, go into your bbPress admin area and add one (you can call the forum category “Group Forums” or whatever you want), then place each group forum under this new category.

    Note down the forum ID of the forum category. You can get the forum category ID by mousing over the “Edit” link and checking the “id” parameter.

    Step #3

    Now that you’ve created a forum category and noted down that forum category ID, we want to hide all group forum related stuff from access and view.

    We’re going to be using _ck_’s Hidden Groups plugin to do this.

    Since you’re using the BP Groups plugin by Burt Adsit, chances are you’re already using _ck_’s Hidden Forums plugin due to its usage with BP Groups.

    Open up the plugin (hidden-forums.php) in a text editor.

    Comment out this line:

    $hidden_forums['hidden_forums']=array(500,501,502); // hide these forums, list by comma seperated number

    Underneath that line, add the following:

    $bp_hide_group_forum_category_id = 3;

    $hidden_forums['hidden_forums']=array();
    $hidden_forums['hidden_forums'][] = $bp_hide_group_forum_category_id;

    $forums = get_forums();
    foreach ($forums as $forum) {
    if ($forum->forum_parent == $bp_hide_group_forum_category_id)
    $hidden_forums['hidden_forums'][] = $forum->forum_id;
    }

    Change the $bp_hide_group_forum_category_id variable to the forum category ID you noted down in step #2.

    And that should be it! By default, the admin can view every single forum post, so try viewing your bbPress install when you’re logged out!

    #59885
    Anonymous User 96400
    Inactive

    @Bowe

    setting up different group types is fairly easy. You just have to attach some groupmeta to the group, that basically let you add as many types as you’d like. Then you just check the metadata to figure out what type of group you’re in. Using the groups API you can then add different functionality for different groups.

    I’ve written a types-plugin for one of my sites. It doesn’t have an interface, though. The 3 types I needed are hardcoded into it, so it’s really not suited for a release at the moment. There’s also a lot of more stuff, like a shopping cart, part of that plugin. So, I’ve stripped the functions needed for group types out (hopefully al of them).

    First we need to add the addtional fields to our registration form:

    function sv_add_registration_group_types()
    {
    ?>
    <div id="account-type" class="register-section">
    <h3 class="transform"><?php _e( 'Choose your account type (required)', 'group-types' ) ?></h3>

    <script type="text/javascript" defer="defer">
    jQuery(document).ready(function(){
    jQuery("#account-type-normal_user").attr("checked", true);
    jQuery("#group-details").hide();
    jQuery("#account-type-type_one,#account-type-type_two,#account-type-type_three").click(function(){
    if (jQuery(this).is(":checked")) {
    jQuery("#group-details").slideDown("slow");
    } else {
    jQuery("#group-details").slideUp("slow");
    }
    });
    jQuery("#account-type-normal_user").click(function(){
    if (jQuery(this).is(":checked")) {
    jQuery("#group-details").slideUp("slow");
    } else {
    jQuery("#group-details").slideDown("slow");
    }
    });
    });
    </script>

    <?php do_action( 'bp_account_type_errors' ) ?>
    <label><input type="radio" name="account_type" id="account-type-normal_user" value="normal_user" checked="checked" /><?php _e( 'User', 'group-types' ) ?></label>
    <label><input type="radio" name="account_type" id="account-type-type_one" value="type_one" /><?php _e( 'Type 1', 'group-types' ) ?></label>
    <label><input type="radio" name="account_type" id="account-type-type_two" value="type_two" /><?php _e( 'Type 2', 'group-types' ) ?></label>
    <label><input type="radio" name="account_type" id="account-type-type_three" value="type_three" /><?php _e( 'Type 3', 'group-types' ) ?></label>

    <div id="group-details">
    <p><?php _e( 'We will automatically create a group for your business or organization. This group will be tailored to your needs! You can change the description and the news later in the admin section of your group.', 'group-types' ); ?></p>

    <?php do_action( 'bp_group_name_errors' ) ?>
    <label for="group_name"><?php _e( 'Group Name', 'scuba' ) ?> <?php _e( '(required)', 'buddypress' ) ?></label>
    <input type="text" name="group_name" id="group_name" value="" />
    <br /><small><?php _e( 'We suggest you use the name of your business or organization', 'group-types' ) ?></small>

    <label for="group_desc"><?php _e( 'Group Description', 'scuba' ) ?></label>
    <textarea rows="5" cols="40" name="group_desc" id="group_desc"></textarea>
    <br /><small><?php _e( 'This description will be visible on your group profile, so it could be used to present your mission statement for example.', 'group-types' ) ?></small>

    <label for="group_news"><?php _e( 'Group News', 'scuba' ) ?></label>
    <textarea rows="5" cols="40" name="group_news" id="group_news"></textarea>
    <br /><small><?php _e( 'Enter any news that you want potential members to see.', 'group-types' ) ?></small>
    </div>
    </div>
    <?php
    }
    add_action( 'bp_before_registration_submit_buttons', 'sv_add_registration_group_types' );

    Then we have to validate things and add some usermeta when a regitration happens:

    /**
    * Add custom userdata from register.php
    * @since 1.0
    */
    function sv_add_to_signup( $usermeta )
    {
    $usermeta['account_type'] = $_POST['account_type'];

    if( isset( $_POST['group_name'] ) )
    $usermeta['group_name'] = $_POST['group_name'];

    if( isset( $_POST['group_desc'] ) )
    $usermeta['group_desc'] = $_POST['group_desc'];

    if( isset( $_POST['group_news'] ) )
    $usermeta['group_news'] = $_POST['group_news'];

    return $usermeta;
    }
    add_filter( 'bp_signup_usermeta', 'sv_add_to_signup' );

    /**
    * Update usermeta with custom registration data
    * @since 1.0
    */
    function sv_user_activate_fields( $user )
    {
    update_usermeta( $user['user_id'], 'account_type', $user['meta']['account_type'] );

    if( isset( $user['meta']['group_name'] ) )
    update_usermeta( $user['user_id'], 'group_name', $user['meta']['group_name'] );

    if( isset( $user['meta']['group_desc'] ) )
    update_usermeta( $user['user_id'], 'group_desc', $user['meta']['group_desc'] );

    if( isset( $user['meta']['group_news'] ) )
    update_usermeta( $user['user_id'], 'group_news', $user['meta']['group_news'] );

    return $user;
    }
    add_filter( 'bp_core_activate_account', 'sv_user_activate_fields' );

    /**
    * Perform checks for custom registration data
    * @since 1.0
    */
    function sv_check_additional_signup()
    {
    global $bp;

    if( empty( $_POST['account_type'] ) )
    $bp->signup->errors['account_type'] = __( 'You need to choose your account type', 'group-types' );

    if( empty( $_POST['group_name'] ) && $_POST['account_type'] != 'normal_user' )
    $bp->signup->errors['group_name'] = __( 'You need to pick a group name', 'group-types' );

    if( ! empty( $_POST['group_name'] ) && $_POST['account_type'] != 'normal_user' )
    {
    $slug = sanitize_title_with_dashes( $_POST['group_name'] );
    $exist = groups_check_group_exists( $slug );
    if( $exist )
    $bp->signup->errors['group_name'] = __( 'This name is not available. If you feel this is a mistake, please <a href="/contact">contact us</a>.', 'group-types' );
    }
    }
    add_action( 'bp_signup_validate', 'sv_check_additional_signup' );

    And then we set up the group for the user (there are some constants in this function, so you’ll need to change that):

    /**
    * Create custom groups for skools, biz and org accounts
    * @since 1.0
    */
    function sv_init_special_groups( $user )
    {
    global $bp;

    // get account type
    $type = get_usermeta( $user['user_id'], 'account_type' );

    if( $type == 'normal_user' )
    {
    // Do nothing
    }
    elseif( $type == 'type_one' || $type == 'type_two' || $type == 'type_three' )
    {
    // get some more data from sign up
    $group_name = get_usermeta( $user['user_id'], 'group_name' );
    $group_desc = get_usermeta( $user['user_id'], 'group_desc' );
    $group_news = get_usermeta( $user['user_id'], 'group_news' );

    $slug = sanitize_title_with_dashes( $group_name );

    // create dive skool group
    $group_id = groups_create_group( array(
    'creator_id' => $user['user_id'],
    'name' => $group_name,
    'slug' => $slug,
    'description' => $group_desc,
    'news' => $group_news,
    'status' => 'public',
    'enable_wire' => true,
    'enable_forum' => true,
    'date_created' => gmdate('Y-m-d H:i:s')
    )
    );
    // add the type to our group
    groups_update_groupmeta( $group_id, 'group_type', $type );

    // delete now useless data
    delete_usermeta( $user['user_id'], 'group_name' );
    delete_usermeta( $user['user_id'], 'group_desc' );
    delete_usermeta( $user['user_id'], 'group_news' );

    // include PHPMailer
    require_once( SV_MAILER . 'class.phpmailer.php' );

    $mail = new PHPMailer();
    $mail->IsSMTP();
    $mail->Host = SV_SMTP;

    $auth = get_userdata( $user['user_id'] );
    $profile_link = $bp->root_domain . '/' . $bp->groups->slug . '/' . $slug . '/admin';

    $message = sprintf( __( 'Hello %s,

    we have created a group for your business or organization. To get more out of your presence on Yoursitenamehere please take some time to set it up properly.

    Please follow this link to fill in the rest of your profile: %s

    We wish you all the best. Should you have any questions regarding your new group, please contact us at support@yoursitenamehere.com.

    Your Yoursitenamehere Team', 'group-types' ), $auth->display_name, $profile_link );

    $mail->SetFrom("support@yoursitenamehere.com","Yoursitenamehere");
    $mail->AddAddress( $auth->user_email );

    $mail->Subject = __( 'Your new group pages on Yoursitenamehere', 'group-types' );
    $mail->Body = $message;
    $mail->WordWrap = 75;
    $mail->Send();
    }
    }
    add_action( 'bp_core_account_activated', 'sv_init_special_groups' );

    When you write a group extension we’ll have to swap the activation call with a function like the one below to be able to check for group types.

    /**
    * Replacement activation function for group extension classes
    */
    function activate_type_one()
    {
    global $bp;
    $type = groups_get_groupmeta( $bp->groups->current_group->id, 'group_type' );
    if( $type == 'type_one' )
    {
    $extension = new Group_Type_One;
    add_action( "wp", array( &$extension, "_register" ), 2 );
    }
    }
    add_action( 'plugins_loaded', 'activate_type_one' );

    The last thing we need to do is add our group type names to group and directory pages:

    /**
    * Modify the group type status
    */
    function sv_get_group_type( $type, $group = false )
    {
    global $groups_template;

    if( ! $group )
    $group =& $groups_template->group;

    $gtype = groups_get_groupmeta( $group->id, 'group_type' );
    if( $gtype == 'type_one' )
    $name = __( 'Type 1', 'group-types' );

    elseif( $gtype == 'type_two' )
    $name = __( 'Type 2', 'group-types' );

    elseif( $gtype == 'type_three' )
    $name = __( 'Type 3', 'group-types' );

    else
    $name = __( 'User Group', 'group-types' );

    if( 'public' == $group->status )
    {
    $type = sprintf( __( "%s (public)", "group-types" ), $name );
    }
    elseif( 'hidden' == $group->status )
    {
    $type = sprintf( __( "%s (hidden)", "group-types" ), $name );
    }
    elseif( 'private' == $group->status )
    {
    $type = sprintf( __( "%s (private)", "group-types" ), $name );
    }
    else
    {
    $type = ucwords( $group->status ) . ' ' . __( 'Group', 'buddypress' );
    }

    return $type;
    }
    add_filter( 'bp_get_group_type', 'sv_get_group_type' );

    /**
    * Modify the group type status on directory pages
    */
    function sv_get_the_site_group_type()
    {
    global $site_groups_template;

    return sv_get_group_type( '', $site_groups_template->group );
    }
    add_filter( 'bp_get_the_site_group_type', 'sv_get_the_site_group_type' );

    It’s quite a bit of code, but it should get you started. This hasn’t been tested with 1.2 btw.

    #58439
    D Cartwright
    Participant

    @Boone Gorges

    Initially I wanted to have the wiki pages privacy completely controlled by the group privacy level but unfortunately we have a need to be able to ‘unhide’ individual wiki pages so in the implementation we’re working on pages will be individually controlled via the group wiki admin page.

    @nexia

    As stated above, I completely agree. Whilst the work we’re doing at the moment will involve mediawiki I think it’s highly likely that I’ll simultaneously (though at a much slower pace) work on something similar to you’re describing in your last post.

    #57379
    maburker
    Participant

    I am sorry the bp-core-adminbar.php

    #56682
    Brajesh Singh
    Participant

    hi

    This is a css problem.

    Put something like this in the theme css(which ever blog theme you are using)

    body {padding-top:28px !important;}

    and The top bar will no more hide the theme.

    Hope it helps.

    btw,you need to have adminbar css in all your themes in order to enable visibility of admin bar.The best way is use import url syntax of css and import adminbar.css from one theme to all the themes.

    #56548

    In reply to: what about bp-plugins?

    Xevo
    Participant

    You can hide the plugins panel in the administration area from your users and you can use plugincommander to choose which plugins should be activated for users and which shouldnt be.

    Personally I don’t see why you would make a plugin folder for a plugin. If every plugin started doing that, then we’d have a lot of plugin folders. :)

    #56312

    In reply to: Broken activity

    arghagain
    Participant

    OK, I saw this in bp-activity.php:

    /* Drop the old sitewide and user activity tables */

    $wpdb->query( “DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_user_activity” );

    $wpdb->query( “DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_sitewide” );

    And so I look in the db and saw there is no bp_activity_user_activity table, and there is no bp_activity_sitewide table. This means it’s a good thing since these got dropped.

    Though I saw this

    $sql[] = “CREATE TABLE {$bp->activity->table_name}

    but to my lack of knowledge of programming, I see this and think it’s bp_activity_something (but no idea)…

    Looked everywhere and I only saw this in db bp_activity_user_activity_cached. This table doesn’t look like it was created by

    $sql[] = “CREATE TABLE {$bp->activity->table_name}, but I could be wrong because I looked at the part under $sql[] = “CREATE TABLE {$bp->activity ->table_name} and saw similar rows get created and these rows are in my bp_activity_user_activity_cached table.

    For example, in bp-activity.php,

    function bp_activity_install() {

    global $wpdb, $bp;

    if ( !empty($wpdb->charset) )

    $charset_collate = “DEFAULT CHARACTER SET $wpdb->charset”;

    $sql[] = “CREATE TABLE {$bp->activity->table_name} (

    id bigint(20) NOT NULL AUTO_INCREMENT PRIMARY KEY,

    user_id bigint(20) NOT NULL,

    component_name varchar(75) NOT NULL,

    component_action varchar(75) NOT NULL,

    content longtext NOT NULL,

    primary_link varchar(150) NOT NULL,

    item_id varchar(75) NOT NULL,

    secondary_item_id varchar(75) NOT NULL,

    date_recorded datetime NOT NULL,

    hide_sitewide bool DEFAULT 0,

    KEY date_recorded (date_recorded),

    KEY user_id (user_id),

    KEY item_id (item_id),

    KEY component_name (component_name)

    ) {$charset_collate};”;

    require_once( ABSPATH . ‘wp-admin/upgrade-functions.php’ );

    dbDelta($sql);

    In my current db, table bp_activity_user_activity_cached has everything except hide_sitewide row. In my current db, table bp_activity_user_activity_cached has extra rows that function_bp_activity_install doesn’t have such as date_cached and is_private rows.

    Any suggestion? What rows should I add or remove? Am I looking at the right stuff?

    Looked like at the end of the function bp_activity_install(), it has require_once( ABSPATH . ‘wp-admin/upgrade-functions.php’ );

    dbDelta($sql);

    Maybe the upgrade-functions.php had not gone smoothly?

    #55615
    still giving
    Participant

    A dropdown admin bar, that hides itself, would be nice as a standard option.

    At the very least it dominates all theme design at present, at worst it interferes with the lay out of others themes.

    Added this to the trac for you as it’s a confirmed bug. I spent a few minutes wrestling with it and found that the posting mechanism is tied to the check_is_member function, even though is_site_admin is used to make the post-form visible.

    A quick fix would be to hide the post-form even for site admins, but I’d rather rebuild the access check to allow admins + group members to post on the group wire.

    stwc
    Participant

    WPMU 2.84, BP 1.1.2, subdir install upgraded with no issues from 1.1.1 to 1.1.2 using autoupdater.

    This seems like a bug and a fairly minor one, but just checking. If I’m logged in as admin, viewing a group that I don’t belong to, the Wire message box appears in that group for me, and I can type something in and hit submit, but nothing happens. No warning, and nothing appears on the Group’s wire.

    If I join the Group, the Wire message appears as expected.

    Preferred behaviour, I guess, would be to either hide the Wire message box and instead show a warning that I can’t post to the Wire unless I join the group (if that’s the intended functionality — I’m not 100% sure, which is why I’m asking here).

    #53310
    ryans149
    Participant

    Hey, thanks. You are great!!! I was looking for the same

    #53306
    Andy Peatling
    Keymaster

    In your wp-config.php add the line:

    define( ‘BP_DISABLE_ADMIN_BAR’, true );

    #53304
    Rahul Sonar
    Participant

    socialpreneur

    I didnt get a single one. can you give me any suggestion?

    Thanks

    #6769
    knight_
    Participant

    Hello,

    I’m hoping someone can help me with a major problems that I’m encountering with my BP installation.

    I’m running WordPress MU 2.8.4. and BuddyPress 1.0.3

    1) After registering, when a user gets the “Activate avatar” e-mail and clicks on the link they see their avatar. It’s uploaded just fine but the cropping tool is missing! So after proceeding you end up with the infamous bacl box. If you click on change avatar, this time it works fine and cropping tool functions properly.

    2) Another cropping tool problem. This time with groups. The group avatar is uploaded fine. The cropping tool functions fine. Once you click on “Crop Full Size and Save” a new page comes up with:

    Are you sure you want to do this?

    Please try again.

    You click on Please try again. and it takes you back. Same thing happens if you try again.

    If you skip this step and finish creating the group. Then go to admin->group avatar and upload and crop the avatar it works fine.

    3)Is the the abillity of users to delete their account disabled by default? If so how do I enable this? This is very important. I have seen it in another installation of BP.

    For example: http://bp-dev.org/members/MEMBERNAME/settings/delete-account

    However that page is missing in my installation but the code seems to be in the core files.

    4) How can I disable/remove the activity labels across the board that display “active X time ago”. Most users obviously want to hide their online status and don’t want others to see when they logged in and for how long. Ideally this would be a user defined setting but since it’s not, how can I disable this?

    Thanks.

    #53227
    takuya
    Participant

    There’re plenty ways! Search the plugins from Developer menu.

    #6751
    Rahul Sonar
    Participant

    Is there any way to hide this option for all users?

    http://i34.tinypic.com/2me7djn.jpg

    #53049

    In reply to: Hide Admin

    johnegg
    Participant

    Any update on this?

    #6600
    FetchFlow
    Participant

    I want to hide a specific member from everyone. It’s the member I used to create the admin for the forums. Name is forumadmin, so that doesn’t make much sense on a listing of hotels.

    #6591
    Jeff Sayre
    Participant

    Many people have been inquiring about privacy options in BuddyPress. Some of you are aware that I am currently coding a Privacy Component for BuddyPress. I decided that it is time to fill the community in on my component, providing more details and a timeline.

    My Privacy Component will be entering a private alpha early next week. After the alpha phase is complete, it will then be available as a public Beta. If it goes well, and Andy likes it, it may be included in the BP core for version 1.2. If you look at the BP roadmap, you will see that that is when privacy filtering is scheduled to be included in core.

    In this screen capture of one of the privacy setting screens, you can see that there are actually six user classification filters that can be chosen for each BP object. The sixth option, “Relationship Mapped”, is made available by a separate plugin which I’ll be releasing later. The default Privacy Component will offer five levels.

    My current estimated release date for the first public beta is the week of October 5. This date may change depending on the feedback from the alpha phase.

    More Details

    This is taken from the Privacy Component’s current readme.txt file:

    BPAz is a privacy control component for BuddyPress that provides a site’s users a mechanism with which to control who has access to which pieces of their personal data.

    == Description ==

    The BuddyPress Authorization component (also referred to as BPAz, BP-Authz, or BuddyPress Privacy Component) is a BuddyPress component that allows users fine, granular control over who has access to which pieces of their personal data. It provides this service by hooking into BuddyPress’ core functionality, thereby giving users the ability to control (grant or deny) access to each piece, or grouping of, their personal data.

    The term “auth” is often used interchangeably for authentication or authorization. There is significant difference in meaning between them. Authentication is not authorization. Authorization is not authentication. Authentication must come before authorization. Authentication is handled by WPMU, initially by the registration process and subsequently by the login script. Authorization deals with verifying and managing the access rights a given authenticated user has to certain objects.

    Because of this confusion, the process of authentication is now often referred to as A1, or AuthN, or simply Au. The process of authorization is now often referred to as A2, or AuthZ, or simply Az. Since authentication must come before authorization, the A1-A2 ordinality of the terms is evident. This also explains the alternate names BPAz and BP-Authz.

    BPAz deals with authorization by verifying and managing access rights an authenticated user has to other’s objects–although a user may choose to expose their data to non-logged in users as well.

    The core BuddyPress objects on which rights can be set:

    • xprofile fields
    • activity stream actions
    • friends list
    • groups list
    • messaging
    • blogs
    • wire
    • status updates

    The basic access levels configurable per object (some objects offer only a subset of these rights):

    • allow/deny anyone (globally public or globally private). This is accomplished by setting an object’s viewing rights to either “All Users” or “Only Me”
    • allow only “Logged in Users” to view a given object
    • allow only friends to view a given object
    • allow only a specific list of users to view a given object. This is also called per user access control. This is accomplished by setting an object’s viewing rights to “These Users Only” and then entering a comma-separated list of usernames (a member’s login name) in a textbox that becomes visible.

    NOTE: Per relationship-type access control is possible if you use my BuddyPress Relationship Mapping plugin. For instance, allow by friend, colleague, partner, client, customer, fan, etcetera.

    Site Administration of BuddyPress User Privacy Tools

    Site administrators have ultimate control and oversight over the configuration of BPAz’s features and functionality via an additional administration panel under the BuddyPress menu hierarchy. The BuddyPress Privacy Component is enabled by default for all object groupings. However, Site Administrators can disable user-configurable sitewide privacy, or even individual privacy control objects, by using the Privacy Settings administration panel. As the Site Administrator, you will always be able to see each user’s complete content. Users do not have any options to hide content from Site Administrators.

    #51822
    peterverkooijen
    Participant

    Yes, I already use wp-hide-dashboard. It’s a partial solution.

    Users still get the pushy wp-login every now and then, which is a problem because it also has a link to an ancient register/signup form that clashes with Buddypress.

    wp-admin/profile.php also is not whacked by wp-hide-dashboard.

    madloki
    Participant

    Hello folks!

    First: a really great plugin :)

    But i have some questions:

    1) Is it possible that user can register only ONE blog?

    2) Can i hide some widgets from guest? It´s not good when anyone can see what users are doing (side wide activy f.e.).

    3) I have read about the manjo gallery, an own user gallery would be great. Is there any news?

    4) How can i use the img tag in groups? I have installed the img-plugin for bbpress, but it doesn´t work in buddypress.

    5) The admin can limit the user mb-limit and upload limit. But the last doesn´t work. I can upload bigger files! Also it would be good if we could change the limit for different user (admin 25 MB f.e. is not so good :o)).

    Edit:

    1) I found this http://buddypress.org/forums/topic/only-one-blog-for-user and will try it, ok good. And the other questions? :p

    So long, many thanks from germany!

    Kind regards

    Markus

Viewing 25 results - 851 through 875 (of 915 total)
Skip to toolbar