Thank you for this very good module that lets you grant access directly where you expect it!

If you use buddylist module you might want to create content that is just visible for people you trust in a certain way. In buddylist you can define buddygroups and decide which users to put into them. Buddygroups might express the level of familiarity and privacy that unites a lot of users. When you grant rights it would be easier to just mark a node to be accessed by a buddygroup rather to type in each username for every node again and again. Node access/privacy per buddy group has been discussed already by the buddylist people in http://groups.drupal.org/node/1715 . I don't see development on that yet, but I think it would be beneficial to corporate with a sophisticated module like nodeaccess instead of making the same thing again (and therefor incompatible).

CommentFileSizeAuthor
#6 nodeaccess-buddylist-patch_0.txt5.11 KBms2011
#5 nodeaccess-buddylist-patch.txt7.28 KBms2011

Comments

Anonymous’s picture

Anonymous (not verified) commented

It's certainly possible, but it would essentially be a new module. I've contemplated things like this but then you just keep running with it and realize that it can't do everything :) I mean, I could add support for access by buddylists, sure. But there are a lot of other things I could add support for, like organic groups, taxonomy, access by menu structure, etc etc. This module is already pretty complex and sometimes I even forget how it all works, the thought of adding more functionality somewhat frightens me... Then you also have the fact that the more realms you support, the harder it is to manage it all since drupal only gives the abilty to grant permissions and not anything more complicated...

marcor’s picture

marcor commented

Thank you very much for your detailed resonse! In the modules list I see access modules to create sitewide roles (simpleaccess). I notice modules that establish access by taxonomy (taxonomy access, tac lite). I see modules that make node access by open group (og audience). We also have another module (framework) that offers access by user (ACL). But I don't see a module that lets me as a simple user decide easily to whome I offer my particular content in a node. And from whome I want to hide it.
Buddygroups (in buddylist) already let me define a group that I consider to be trustworthy in conjuction with a whole topic. It's the way I think when I would give private access to a node's content. Community members need the believe in the site's privacy, if you want to encourage them to tell personal things. From my point of view, this feature would give a solution that makes nodeaccess easier to use, because there are only a few buddygroups so we could give a drop down list or checkboxes instead of an empty textfield (and additional keep?-markers).

OK, let's say I really need this feature for my site before it gets published. What would I have to do to build this functionality with nodeaccess, that it will not injure current nodeaccess functionality? To whome can I talk to discuss the database design?

themselves’s picture

themselves commented

I'm not sure about how one would actually go about implementing this in Drupal, but I can tell you, I'd love this functionality to exist right now. I've been tasked with building a site for users to upload and share data, blah blah blah, but one of the features is the ability to set nodes as "friends only". This would be *perfect* for buddylist, whereby I could simply add a checkbox to node types saying "is this for your buddylist users only?" and then a simple access hook - when someone views the node, if they are in the list, fine, otherwise it's no go.

Of course, this is probably missing a whole lot of other areas, like views displaying teasers and all that. I'm 3 weeks nub to Drupal, and in a lot of ways, I have no idea what I'm talking about. Anyway, this sort of functionality seems like a natural thing to me, and is far easier than OG - which in itself is awesome, but overkill for a system like this.

chrisroditis’s picture

chrisroditis commented

subscribing!

ms2011’s picture

ms2011 commented
Title: Node Access for Buddy Groups » Node Access + Buddylist integration and support for other modules
StatusFileSize
new nodeaccess-buddylist-patch.txt7.28 KB

I took a stab at this request. This patch will allow you to restrict node access to buddies of the node author--a lot like myspace. You could pretty easily use this example to build the same thing for Buddy Groups.

Although I can get around Drupal pretty well by now, I would still classify myself as a beginner--try at your own risk.

I also would like to suggest that the author of this module provide a way (probably via hooks) to integrate with other modules. Ideally, I would have liked this to be maintained as a contrib module to buddylist or as its own module buddynodeaccess.module or something. Just an idea.

Hope this helps someone! :)

ms2011’s picture

ms2011 commented
Version: master » 5.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new nodeaccess-buddylist-patch_0.txt5.11 KB

There was an important bug fixed in the nodeaccess module since the prior version.
This is an updated patch for nodeaccess.module version 5.x-1.x-dev released 2007-Apr-30.
I also fixed a bug in my patch above.

ju.ri’s picture

ju.ri commented

I tried this patch and it works very well so far. Thanks a lot!!
I hope this will be continued in some way. the settings page has exactly the options that i need for my site :)

dharamgollapudi’s picture

dharamgollapudi commented

Subscribing....for further study of the module

ju.ri’s picture

ju.ri commented

ok... there seems to be a bug. buddylist access control works well for existing content and users. but when a new user registers through invite module (and is automatically added to a buddylist), access to this buddy's content is not granted. after resaving each node, access is granted again. after resaving the nodeaccess module's settings, access is also restored. hope this helps someone..
this is after applying the patch to the right cvs version of the module, and also after manually applying the newest changes in cv code.

Christefano-oldaccount’s picture

Christefano-oldaccount commented

subscribing

BA53’s picture

BA53 commented

Nice feature! Would love to have it included in the module! That's really something Drupal is lacking. Something facebook-like.

Damjan Dvorsek’s picture

Damjan Dvorsek commented

Also subscribing

omnyx’s picture

omnyx commented

this is a great feature - exactly what is missing. It'd be great to see it fully implemented with nodeaccess...

Since i'm a newbie I have two questions:
1. how do I apply a patch? I know there's the console way but is it possible to just copy and paste the code and if so, to which file and where in that file should I paste the code to?

2. ju.ri, you mentioned that the patch doesn't work well for users that are registered through 'invite' option? is it only to them? so, would visting the settings for nodeaccess module and simple resaving it work as a temporary fix? :)
does anyone know how one could get around this problem? IMO, it doesn't look complex to change it, but i might be gravely mistaken :)

please help if you can...many thanks for this. I'll keep my eye on it :)

ju.ri’s picture

ju.ri commented

> 2. ju.ri, you mentioned that the patch doesn't work well for users that are registered through 'invite' option? is it only to them? so,
> would visting the settings for nodeaccess module and simple resaving it work as a temporary fix? :)

i think it's not a problem of invite module, but more general. the node access table doesn't seem to get updated when buddy relations change.
yes, resaving the settings updates the tables, as well as resaving the nodes.

B747’s picture

B747 commented

Also note that there's a way to restrict profiles to buddies:
http://drupal.org/node/93981

and profile fields:
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/profile_priva...

gagarine’s picture

gagarine commented

subscribing

Jay Armstrong’s picture

Jay Armstrong commented

subscribing

STyL3’s picture

STyL3 commented

subscribe.

droople’s picture

droople commented

subscribe

pwhite’s picture

pwhite commented

subscribe

mantyla’s picture

mantyla commented
Project: Nodeaccess » Buddylist2
Component: Code » Buddy API
Assigned: Unassigned » mantyla
Status: Needs review » Active

1, 2, 3, 4... 16 requests for this feature. Too many to ignore. But... I still agree with debtman7 in his early reply, that this would essentially be a new module. There isn't any need to integrate this into Nodeaccess, and it would make more sense to make it an add-on to Buddylist2.

So here's what I suggest: as I am now a co-maintainer of Nodeaccess and I know its code inside and out, I could write such an add-on in a way that doesn't prevent it from working in harmony with Nodeaccess. The trick is in the priority setting, which most access modules sadly lack or fail to use to its full power, despite it being supported in Drupal core. The current Nodeaccess has a priority setting of either on or off, but in the next version the priority range will be from -10 to 10.

If two modules have the same priority, both of their grants will be applied to nodes, and if either one gives access, access is granted. Only if neither grants access is access denied. If, however, one module has a higher priority than another, then the grants of the module with the lower priority will not be applied at all. You could give Buddy Access a priority of 10, and you could rest assured that no other access module is going to overrule its settings - currently only Content Access has the potential to match it, and you'd have to deliberately configure it to do so.

So, let's hear some thoughts. This is a somewhat old topic, and I don't know if you still want such a module. And, what sort of functionality would you want? Judging by the patches I looked at above, all you'd want is a global, or maybe content type specific, setting for which grants to give to buddies: view, edit and/or delete. What else? Should there be defaults for different content types, or would you need to choose on a per-node basis if you wanted to use buddy access?

4drian’s picture

4drian commented

If anyone is looking at developing any sort of node access system, can I recommend taking a look at http://drupal.org/node/196922 where the issue of having multiple acl grants is discussed in some detail. The thread is largely to do with submitting a patch to core for d7 and from what I gather it is a very efficient and non-intrusive way of doing it. For those daring enough to patch core, the functionality is available for d5 already and is being actively watched by a number of 'high-profile' drupalers.

nodestroy’s picture

nodestroy commented

interesting thing, i would prefer to implement this for buddylist2 for drupal6 (and then maybe merge back to drupal5). The first usecase would be to restrict profile access to buddies, but there should be the possibility for EACH user to decided (All users can access my profile / Only my buddies can access my profile)

@mantyla: do you think, that this is possible with a small lightweight module?

mantyla’s picture

mantyla commented

Sorry, but I don't think that particular use case is possible at all without patching core. The function used to determine access to profiles is user_view_access, and it offers no means for contrib modules to have a say. Access to nodes is determined by node_access, which takes module input into account.

The easier part is restricting access to nodes, and I believe that is doable with a small module - depending on the functionality expected of it.

nodestroy’s picture

nodestroy commented

I forgot to mention, with profile i mean a simply node, like http://drupal.org/project/nodeprofile. I´m not very familiar with the node_access thing, i only found hook_access "This hook allows node modules to limit access to the node types THEY define". So, maybe you have some sample code, or a little hint to understand?

I think the best way would be:
- admin can choose what content types can be restricted by users (blogposts, userprofile,...)
- each user can choose who can access this content, best way would be per node (this blogposts is visible to all users/this post only to my buddies)