BuddyPress.org

thanks, I created my first ticket! lol https://trac.buddypress.org/ticket/1027

The answer is yes and no.

The privacy component is designed to offer users a mechanism to assign access rights (viewing rights) to their various core BP object groupings. It is not designed to let users assign per-item access control to any and all objects. So, for instance as you suggest, at this stage a user will not be able to assign an individual image discrete access rights. Why? Because photos (album objects) are not part of BP’s current core.

Please be advised that this component only provides the assignment of privacy levels to BP’s core object groupings. All 3rd-party components will need to code their own privacy control features–using this component as a model and tying into its access-control table.

Remember that this is a first version Privacy Component, so new features will be added later.

A little more about access control

Typically, Access Control Lists and protocols focus on flexibly setting access rights to resources based on predefined roles (for example: site admin, group admin, moderator, editor, contributor, member, user). This type of access control is more often called, and more appropriately referred to as, role-based access control (RBAC). Role-based AC is necessary when two or more people are involved in the management, oversight, and even ownership of specific subsets of data. This group of people then need to be jointly authorized to perform certain functions.

But BuddyPress is a user-centric platform where there are currently no-jointly owned or controlled subsets of data. Ignoring the overall Site Administrator, in BuddyPress, there is a one-to-one relationship between a given piece of data and a single owner of that data. Even groups (at this time) are owned and controlled by one user. Group Moderators are limited in their power and do not own anything.

The core BP privacy component is what I am calling a light-weight ACL implementation. At some point it may make sense to offer a separate, full-fledged RBAC system but I’m guessing that only a few devs who truly understood such a system would take advantage of it.

Offering privacy control on BuddyPress’ core component objects is more than sufficient.

Jeff: Yeah i made a ticket as well here: https://trac.buddypress.org/ticket/1023#comment:6

Looks like Andy already fixed them in the trunk.

good that the TRAC-ticket has been re-opened again:

this issue is not about which browser you are using or hardware !

https://trac.buddypress.org/ticket/1021#comment:3

There is clearly something wrong with the mouse-over at the homepage of testbp.org !

the mouse-over is behaving perfect and very fast at an individual user-blog at testbp.org

Here’s a one-page PDF that shows the 6 access control levels of BPAz:

http://www.sayremedia.com/buddypress/BPAz_Access_Levels.pdf

@jjj

I had considered adding the ability to block a certain user or groups of users but then realized that the selections that are offered do in fact block groups of users by virtue of them not being able to view a given object. For example, if a particular user is bothering you, and they are not in your friends listing, you can make an object only viewable to friends. This, in essence, will block them.

Possibly future versions of the component could enable the grouping of several filter options or even include the ability to filter out certain users. But suffice it to say that the first version offers plenty of options and flexibility.

@Erich73

Since forums are not a core-created object but in fact are objects pulled into BuddyPress from an outside plugin, BPAz will not offer a filtering option for forums. There are simply too many distinct objects that bbPress creates. It truly needs its own privacy filtering system. Therefore, it is up to bbPress to offer such privacy options or a 3rd-party bbPress developer.

Jeff:

1. Which version of WPMU are you running?

2.8.4a

2. Did you install WPMU as a directory or subdomain install?

directory

3. If a directory install, is it in root or in a subdirectory?

subdirectory (domain.com/designs/wpmu)

4. Did you upgraded from a previous version of WPMU? If so, from which version?

No I made a clean install

5. Was WPMU functioning properly before installing/upgrading BuddyPress?

Yes. Login was working fine. When I installed buddypress I couldnt login from the buddybar login. It looks for wp-admin.php in the root instead of in the directory “designs/wpmu/” where wp-admin.php is located.

6. Which version of BuddyPress (BP) are you running?

1.1 beta

7. Did you upgraded from a previous version of BP? If so, from which version?

No clean install

8. Do you have any plugins other than BuddyPress installed and activated?

Only Buddypress

9. Are you using the standard BuddyPress themes or customized themes?

Standard that comes with buddypress

10. Have you modified the core files in any way?

No

11. Do you have any custom functions in bp-custom.php?

No

12. If running bbPress, which version?

bbpress 1.0.2

13. Please provide a list of any errors in your server’s log files.

When logging in from the buddybar it cant find wp-admin.php as its looking for the file in domain.com and not in the correct location which is domain.com/designs/wpmu where wp-admin.php is located.

When clicking login I get the message “No input file specified.”

I even tried making a clean install once again. Same problem with buddybar!

perfecto! had one *slight* mistake in that setup … i dumped everything into /plugins/buddypress/bp-forums/ … without the bbpress folder and yes, it was via zip, lol.