This is not an issue, more than feedback about the module... so I'm not sure if this is the right place to post. If not, just ignore it or just suggest me to cut the post into direct and clear questions. :-)

Finally we installed the module and apart of the issues related with mark module (reported and fixed in other issues) the module works fine and it's API opens a new perspective to deal with content access in OA installations (features, spaces and so on).

Without looking yet into the code, if we catch how it works, the module+feature enables a mark dropdown in every content-type where you can select group's nodes default privacy between "same as group's", "default: public" and "default: private".

It works like a charm with Public spaces (as far as the group access is open and privacy is defined by the node) but we found it a little confusing with Private spaces.

If the group is Private, the restriction is done at group's level, so never mind the default node permissions.

This is not really a big deal if you can switch your perspective: Just turn all your site's group-spaces to public and let og_privacy do it's work.

Spaces profiles won't control access. They will control the kind of membership and features enabled and so on.

The only problem we found with this approach is related with features.

Access control to features aren't yet controlled by og_privacy so non-members will be able to see, for instance, the lists Members or the group dashboard, or whatever that is not a node. :-(

So this is our final question (as is said, before we found time to look into the code): Is possible to extend the code to deal with this kind of situation?

Any case, thanks a lot to grayside to share this valuable piece of code.

Cheers,
m.

Comments

mbria’s picture

mbria commented

After testing the module from the user/admin perspective is time to look into the code.

From grayside's blog (that I didn't know until today) I found an answer to my feature-privacy question:

"For an example of an exclusive policy, which exercises supreme executive veto power to guarantee the privacy of, say, all the content from your Atrium Casetracker feature, it might look like this..."

So looks he took in consideration the issue that concerns us and with a little bit of code features could include a "mark" to make them private (hidden to non-members).

I'm trying this right now and I'll be back in hours.

mbria’s picture

mbria commented

I'm double posting here and in grayside's blog to keep this thread up to date.

Just to start I tried grayside's exclusive policy posted example but I didn't manage to make it work.

I edited "og_privacy_atrium.module"...

1) to add more policies as follows:

function og_privacy_atrium_og_privacy_policy_info($node) {
  $policies = array();
  
  $policies['og_privacy_atrium_public_node'] = array(
    'access callback' => 'og_privacy_atrium_public_node_access_policy',
    'reason' => t('The <em>Make Post Public</em> checkbox is checked off in Privacy > Advanced settings.'),
  );
  
 //MBR: Added to test "exclusive" feature restriction
 $policies['og_privacy_atrium_casetracker'] = array(
    'access callback' => 'og_privacy_atrium_casetracker_policy',
    'reason' => t('Content types created by the casetracker feature are viewable only by group members.'),
    'exclusive' => TRUE,
  );  

  return $policies;
}

2) Then I implemented a dummy callback (right now, just deny everything):

function og_privacy_atrium_casetracker_policy($node) {
  return FALSE;
}

3) Clearing cache: drush cc all
4) Create a new group in my OA testing site.
5) Enable casetracker in this grou0p.
6) Post a project and some dummy issues.
7) Rebuild permissions (/admin/content/node-settings or drush php-eval 'node_access_rebuild();' )

The result is: visitors CAN see casetracker feature and it's projects&issues. :-(

Any clue about what am I doing wrong?

I will dig it further and I'll come back if I found and answer... but any help is really appreciated.

Cheers,

m.

msielski’s picture

msielski
he/him/his
Primary language English
commented

I have a similar concern, but it's possible I'm just not fully understanding this module. I am using OA 1.0 Beta 8 with the og_privacy_atrium feature.

On public groups this is working well for me, allowing me to make certain posts private. In private groups I don't see any result from making certain posts public. I was hoping they would then show up in the site-wide activity block in the dashboard. I'm thinking along the lines of allowing a private group to publish a press release or event visible to the whole site.

Not sure if this makes sense. Private groups don't even show up in the group listing - maybe they are meant to be invisible. If so, not sure why you would apply this feature to a private group.

Grayside’s picture

Grayside commented

The -dev version corrected a few inconsistencies with where the mark checkboxes were appearing. I haven't had any time to push on this module in the last month, hoping I will be able to break some time off in the next few weeks.

I will try to re-describe how this works, because I am reading a lot of good insight, and a little confusion. And I'll do it in bullet-point form, because it might be more easily digestible.

  1. This module only affects node access. It does not affect access to a Feature or to Views. For that kind of broader access control within OG Privacy, see #921526: Going further with privacy.
  2. This module really only affects public groups. It's name is "Privacy", not "Access Control", because it manipulates the relationship of nodes to OG's access control system. In order to make nodes public in a private group, or make private groups publicly listed, I would have had to rewrite the Access Control system itself. That's definitely doable, but an order of magnitude more complex. It would also be very difficult to maintain compatibility with Spaces.
  3. All the exclusive property does is AND that policy against the rest, which are OR'd together by default. This means that you can create a policy that ignores what other modules say. This allows you to have some guaranteed privacy controls.