I'm trying to do something very similar to http://drupal.org/node/705166 with a slightly different twist.

Here's my use case:
1) The site will have a reviewer to create the original content with some write up about a particular store
2) There will be two types of users (owner of a store & normal user), normal user can comment on any store, owner can edit & upload files to his/her store but cannot change any comments
3) Owners will need to purchase a subscription in order to be able to edit/update their own node

My problem is I don't know how to distinguish if a registered user is a normal user or a owner, and how to link the registered owner to his/her content node

Can you give me some pointers?

Thank you

Comments

RikiB’s picture

RikiB commented

Sounds like you could do this with role permissions easier than node access. That would be my suggested direction.

jeremy.zerr’s picture

jeremy.zerr commented

I concur with RikiB. Here are my initial thoughts.

Have users who want to be owners purchase a product that grants the Owner role, done using uc_roles that comes with Ubercart.

Now is the tricky part that could be done probably many ways, you have to allow the owner to identify a particular Store node. Here is one of the ways I can think of.

You could add a CCK node reference field to the user profile (if you use content profile module) or just to some other node/webform like maybe a store owner application form. That CCK node reference field has autocomplete and would allow the Owner to find a particular node that they would like to be in control of fairly easily by title.

Now, to give the user access to the node.

Using the Rules module, you could read that node reference field upon "user saves content" and then check its value and grant access to the node.
I'm not sure if ACL is integrated with Rules or not, but you could always execute php to grant the user access to the node using ACL module functions.

Let me know if you try this out, I'd like to hear if it works OK.

Thanks, Jeremy

jklcom99’s picture

jklcom99 commented

Hi Jeremy,

Thanks for the suggestion. I'm currently using content profile module for user registration.

Using uc_roles, can I assign different roles to different fields in the content profile node? For instance, only the review can edit the review section, owner of the node can only modify certain basic info such as name, address, images & etc., all others can add comments and it's viewable by all.

About the CCK node reference field, what must be done to this field in order to pull in relevant nodes with autocomplete? I would also like to prevent users from mistakenly or intentionally acquire the wrong node challenging them with a acquiring passcode of some sort.
How can I implement that?

Here's how I'm picturing the workflow:
1) Users register as a normal user to start with
2) A registered user can purchase a "Owner role" and an acquiring passcode will be emailed to purchaser
3) Once role is granted, owner will be able to acquire a particular node with the provided passcode
4) Owner will be able to edit/modify/upload certain info

Please let me know if you have a better approach.

Thanks

jeremy.zerr’s picture

jeremy.zerr commented

You can restrict a certain CCK field to only being edited by someone with a certain role, see the Content Permissions module that comes with CCK. It makes a whole list of view/edit permissions for each CCK field you have in User Management | Permissions once you enable the module.

When you set up a CCK node reference field, you have the option of specifying the content types that will be allowed to be selected. If that isn't sufficient, there is the built-in capability to use a View to provide the nodes that should be able to be selected (see the "Advanced - Nodes that can be referenced (View)" section when you are creating the node ref CCK field). So if you require some more fancy logic, Views should be able to handle it, then you link that to your node reference field.

Jeremy

jeremy.zerr’s picture

jeremy.zerr commented
Status: Active » Fixed

No update on this issue in a while, marking as fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.