private wishlists/items

Yes, this would be a really really great feature! And I think a very essential one. I already thought about that, too, but I cannot imagine yet if this is a feature that is in the scope of a wishlist module...

Roles in drupal are defined site-wide. Another form of personal groups is realized in buddylist (buddy groups) and OG (organic groups). Buddygroups are very close to what we think of: Just I decide, to which group somebody belongs, I define new groups and so I have full control of the privacy-level. Organic Groups are made to let users come together if they share a certain interest. Of course, I could be the moderator of "my" own groups and decide, who can join. This is not handy, but we have OG modules that control the access to certain nodes by OG (http://drupal.org/project/og_audience, http://drupal.org/project/og_public_access). So we could control access to wishlist-items, too.

In my opinion, the cleanest approach would be:

1. Add "node access by buddy"-functionality to buddylist or a module that's based upon buddylist ("buddy access")
2. Rely on "buddy access" in wishlist-module and show this functionality if this module is defined.

The buddylist people already considered to develop this feature but they were not sure if OG will provide more general solution to that problem. As I noticed no actions were taken on that so far. For discussion on that see http://groups.drupal.org/node/1715

But I wouldn't mind if wishlist is faster in developing this on its own! ;) Keep on the very good work! I would like to contribute, if I can...

I just read about the nodeaccess module (http://drupal.org/project/nodeaccess). Could be a nice first step to realize the privacy feature. So everything you would need to do is to represent the node access in the wishlist to show or hide each item according to the corresponding node access.

But still a think a combination with buddygroups would be a better approach. I just made the nodeaccess developers become aware of buddygroups. http://drupal.org/node/122394

@Matthias: Would this feature do what you wanted?
@Scott: What do you think about this feature? Do you think it's realizible? How could I help (having very poor php knowhow)

The effect you are both looking for is an excellent feature. Because the wishlist module creates a new node type, any of the permission handling modules should work with it. Marco is right, this is great feature that is not appropriate for implementation within the wishlist module, but rather is achieved by combining a module such as nodeaccess or simpleaccess with wishlist to control who can see nodes of type 'wishlist' or to control access to specific nodes.

That said I've not used either of those modules and cannot tell you that it all works perfectly.

@MarcoR - you have offered to help. Where I think that help would best be applied is in experimenting with one or more of the existing access control modules in combination with the wishlist module. See what works, and certainly file issues if the design of wishlist prevents an access control module from working. When it comes to storage and access, this module is pretty simple, but I can think of a display or two where I may not be using db_rewrite_sql(), which is the hook needed by access modules to control who can see what. This does not require php knowledge, but rather Drupal knowledge and an understanding of the effect you are looking to achieve. This sounds like it a good match to the skills you've described.

I'm going to leave this issue open for a few weeks so that you can report back progress and findings.

Thank you both for the compliments. I am always glad to hear from folks who find this module valuable.

Scott

Thank you two for your response! @scott: This is exactly what I wanted to do anyway. ;)

I started experimenting already... and I have to WARN you: I had to notice that nodeaccess may become the functionality we need, but for now it's just a mess. After configuration I cannot login anymore, even as an admin. Take the readme serious and BACKUP YOUR DATABASE before using modules dealing with access control.

Will continue experimenting after I took back control. This may take a while, deactivating nodeaccess and running update.php hasn't helped yet. Any suggestions on that are very welcome...

@MarcoR - The way node controls work in Drupal 4.7 and down (I've not gone deep with 5 yet and don't know of proper ACLs (access control lists) were implemented yet is a bit of a pain, and to the best of my knowledge prevents multiple access control modules from co-existing. There is a table that is part of Drupal core that I believe is called node_access. By default it contains very little, just enough to make sure that everybody has access to all node instances for the node types they have been granted access to. When you enable an access control module, such as organic groups or nodeaccess, that default table entry is deleted and replaced with node specific rows to control access. I may have bits of this wrong, but at a high level that is how I understand the access controls to work.

So, given that I believe that you can restore your system to pre-nodeaccess days by

• Opening up the nodeaccess.module code to confirm the name of the node_access table.
• Back up your current corrupted database so you can try multiple solutions
• Find the code in Drupal core that populates the node_access table on a fresh install. That will be the appropriate SQL file under /database.
• Drop the node_access table
• Re-create the node_access table by running the SQL fragment you found in the initialization file.
• It is likely that this will only create the table. Next you will need to sift through the core installation code (search on node_access here again) to find any logic that dumps initial data into this table.
• test.
• If it works, make a backup this time. :)

These are guidelines for an approach and not explicit steps. Follow them if you wish, but also take responsibility for what happens. I'm aiming to help here, but I'm not responsible for you not making a a backup to begin with. :) Now where I am responsible is for not having made backups myself in the past before embarking on experiments like this...

Hi Scott, thank you very much for your advice! :) So I knew I was on the right way (see my struggle-report on http://drupal.org/node/122489). Peculiarly, login was possible from other machines but mine. So I think there had to be side effects to session management. Just deleting sessions and cookies didn't help either. Maybe it had something to do with my settings.php where I've put an IE-Workaround into once giving an explicit sitename which maybe broke my neck on my "localhost". But I didn't find a dependency. Anyway, I'm commanding bridge again.

As far as I took a look into nodeaccess.module it seems to be a nice solution to manage roles as well as users by uid. Case dependent, the realm is called nodeaccess_rid or nodeaccess_uid (and realm all has been dropped, as you mentioned already). So it would be possible to find a new solution for groups implementing a nodeaccess_gid (given the module works properly so far). Besides the original node_access table the nodeaccess module created and filled another nodeaccess (without "_") table. Strange, isn't it? I will set up a test site and give it a look again.

@mattie - have you achieved what you were looking for with other permission/group handling modules combined with wishlist?

@MarcoR - have you found any problems with the implementation of the wishlist module with regard to how it interacts with node permissions handling modules?

sorry, still struggling with my site. I also wanted Open Groups access, and all these access systems seems to work against the other... :(

As this issue seems to have gone dead with no obvious need left to change the wishlist module I'm closing it out. Open it up again if the topic is still live and the wishlist module is part of the solution. I'm still thinking that permission handling is a site-wide feature and not a wishlist specific implementation.