Hello

I really love the feature integrated within the module. It goes beyond the basic public/private paradigm, and offers a level of customization really needed and interesting. Also the fact the feature is in d.o means it has an issue queue ! This rocks !

I was wondering : can your feature hide Features menu entries where all posts are private for the visiting user ? So if I'm anonymous/non-member of group A, and all blog posts of group A are marked private through the feature, it "automagically" hides the blog entry menu so I don't even see it. I don't know if it's possible or clean. I suppose it would require a check to all nodes' privacy (not very efficient), and a kind of unset('blog menu entry'); or hook_menu_alter() (is it clean ?). What do you think ?

Comments

Grayside’s picture

Grayside commented

Interesting thought.

What would need to happen is to implement hook_menu_alter() and replace the access callback spaces_menu_access() with something that:

  1. Call spaces_menu_access() anyway.
  2. If access is denied, return FALSE. Otherwise, continue.
  3. Checks to see that the current user is not a group member.
  4. Executes the blog_listing View (or otherwise some kind of View or query relevant to the Feature) with the addition of WHERE clause/Views filter to restrict it to Public posts.
  5. If that View has no results, deny access.

There are two things in the way of seeing this kind of functionality in the og_privacy_atrium feature itself:

  1. I'm not sure if it would be more or less confusing for a feature to disappear from a public group based on content availability. I know for my projects it's probably a good idea, but I would want a few more votes in favor.
  2. I don't like the idea of a lot of per feature configuration in the code to identify the proper View or SQL query to test for an "empty" feature.

I would be happy to link to any modules/features that add this functionality separately without meeting those requirements.

DjebbZ’s picture

DjebbZ commented

For the 2 things that are in the way of seeing this in your feature :

  1. You have my vote :). The thing is that when no public content is available, the anonymous/non-member will see the feature tab, but once he clicks on it he'll see a disapointing "No content to show". Not very user-friendly, but I can imagine that in some cases this is useful. Not for me or for you apparently.
  2. This is a bigger problem. It may be easy to check for core Atrium features, but for others... Do you think it is possible to make it generic ? Like checking the content types associated with the feature, checking access for listed nodes, and granting access. It seems very complicated...

I will try this week or next, so I'll get back for updates or call for help if needed :)
Thanks a lot for the precise answer.

Grayside’s picture

Grayside commented

I've done some further thinking, and I've got a direction for you. The core of which should not be hosted as part of this project. Here's the "vision":

A "Menu Access Control" module providing a hook_menu_access_policy_info() after the fashion of hook_og_privacy_policy_info(), to be invoked in hook_menu_alter().

og_privacy_atrium or some other module could implement atrium_menu_access_policy_info() with a callback that would check the path of each of Atrium's core features, with a hook so other added Features can get a foot in the door if so inclined.

If the policy is tested and access is denied, well, access is denied. However, if access is granted it should then default to the existing access settings.

There are aspects of this design that bear some careful thinking, because I'm not sure if OG Privacy's pattern makes sense for menu access.

that0n3guy’s picture

that0n3guy commented

I'll through up a vote for this. I'm getting fairly comfortable with node_access, but have never done menu access stuff... just saying that I might not be the guy that does this :).