By zigx on

We are working on a system where the following exists:

- We have Companies
- We have Clients (Users) that need to belong to a Company
- We have "Works" that are done for Clients -- ie. images, video, etc
- We need Clients to have the ability to login and see "works" that have been submitted by our team (admin)
- Works need to support comments.

We are struggling with choosing the best solution for how to segregate Clients/Companies while allowing all of the members of a company to view Works.
Works as a content type with file fields is a given....

Any suggestions would be greatly appreciated.

thanks!

⋅ Categories: Drupal 6.x

Comments

bohz’s picture

bohz commented

I would suggest TAC_lite
and NAT.

There's a very helpful howto in the readme.txt of TAC_lite.

What I would do (actually we are using this setup in a project) is:

  • set up a "work" content type as NAT; this will create a new term in the "Works" vocab for each new "work node" you create (using node title as term name) this would be the "homepage" of the project
  • then, I would tag with this term all the nodes pertaining to the specific project (or "work" in your case); on such nodes you may also add a node reference field pointing to the "work" node created above, in order to have all the content related to the project conveniently summarized there (views aside)
  • using TAC lite, I would grant access to nodes tagged with "Works" vocab only to admins
  • providing you create a user account for each client, from the client user account page, you can assign access grants to content tagged with the specific term (->project), only to the specific client involved

Not sure if this was clear enough, but take a look at the TAC_lite readme.txt, I found it very helpful.

Another way I'd explore would be using node access user reference to grant access for each specific node. But I did not try it yet.

hope this helps
cheers

zigx’s picture

zigx commented

Bhoz,

Thank you for responding!!

one question: Did you explore the use of Organic Groups at all before deciding to go this route?

bohz’s picture

bohz commented

We considered it, but I barely read the docs for organic groups.
We are working for a small company and considered it too much. Thus we moved onto other solutions.
To be honest, I am not even sure it would have been actually too much and I still would like to try OG for similar purposes as soon as I get the chance.
If you do, I'd be interested to know the result.
Good luck with your project!

WorldFallz’s picture

WorldFallz commented

I use organic groups for something very similar and it works great.

bohz’s picture

bohz commented

Your post is tempting me to redesign our project around OG.... ;)
I think I am going to investigate og more carefully.
Thanks!

WorldFallz’s picture

WorldFallz commented

hope it works out. ;-)

bohz’s picture

bohz commented

..may I ask if you think OG would apply to our situation:

same as the original post but in our case, each client/company would need to have privileged access to a group of nodes (the project) owned by different combinations of freelancers.

In other words, it's an association of freelancers whose members gather in different combinations for each project, hence each client.

We need to be able to assign user-level access permissions to each "project category" for both clients and freelancers.

Do you think OG would do the trick?

Thanks

WorldFallz’s picture

WorldFallz commented

I'm not sure I understand 100% but OG doesn't have any type of user level permissions.

What I did was use the og_user_roles module which allows me to assign permissions based on roles that are specific to a group. In other words, someone may be in the "editor" role for group1 but in the "reader" role for group2. Is that what you mean?

bohz’s picture

bohz commented

We have 2 roles: freelancers and clients.
- Freelancers are always "editors" and client are always "readers".
- Individual freelancers may be in group1 but not in group2.
- Each group=project should have its own specific set of "editors" and "readers"

A good analogy would be a collection of players from which you can pick a different team (->a group) for each specific match (->the client)

Hope it's understandable, I'm not very good at making myself clear..sorry

WorldFallz’s picture

WorldFallz commented

Yep, from your description you should be able to do this with organic groups + og_user_roles.

bohz’s picture

bohz commented

Our setup was simpler than I thought.
I set up one private group for each project with its own clients and freelancers
"client" role can only see the content while "freelancer" role can edit own content.
That's it. Easy

Moreover, although TAC_lite doesn't work in conjunction with OG, It still works with content not included in groups, so we can enable special cases for nodes that should not be accessed by clients, regardless the project.

Thanks for your suggestions!