By drupalninja99 on
Here's the issue.
I would like to have users sign up an account and by doing so create their own user group, let's call it an office. Then they should be able to invite other people into their office, lets call them "agents." Agents would have their own data that only they could see, let's say information about their contacts, for example.
Ideally the members of the "office group" would have some shared data, but then some private data only seen to them.
Is this at all possible within drupal?
I realize with taxonomy access you can allow roles to have their own data, but it's kind of a pain to set that up. It means the administrator has to keep creating roles all the time and has to configure them with tax access.
Any ideas?
Comments
maybe hacking on the
Maybe hacking on the node_permission_by_role module would be of benefit? You'd have to hack the node add hook to make items visible only by the role of the user - shouldn't be too hard, really. But you'd have a role for each "office" - not sure if that suits your application.
where's that module located?
i'd be willing to do anything really to make it happen.
i really don't want a million roles
in my mind there are only 3 roles this application needs, anonymous, office admin, & employee. The office admin adds employees to his user group. They have shared data that other offices can't see. Something like that.
I want the quickest dirtiest way to get this done, I'll try anything.
Have you taken a look at the
Have you taken a look at the og modules and the gojoingo group of modules? Both are in listed in projects.
Regards
Patrick Nelson
=================================================================
All truth goes through three stages:
- First, it is ridiculed,
- Then it is violently opposed,
- And finally it is accepted as self-evident
vcommunity.org.uk - the business-to-business network for the UK
does gojoingo have any documentation?
i downloaded the module but it'd be nice if there was some documentation to look at.
What kind of documentation are you looking for?
There are README files littered throughout that describe what the various modules/patches are for and what they do as well as an installation document and a script which grabs all the stuff for you and patches it.
The current version of Gojoingo is lacking.
Sorry if I don't understand the thinking behind gojoingo but it seems to be going in a direction than I am ...
I downloaded the current version and it basically says it's a collection of other modules.
Then when I tried to install it, I was referred to a long thread about CivicCRM install techniques which didn't help at all.
Is there a new and improved way to install gojoingo that's being worked on behind closed doors?
Confused.
http://www.webwiseone.com
It's all about community.
https://bkjdigital.com
We make magic.
Consider TAC Lite which is
Consider TAC Lite which is similar to Taxonomy Access but allows you to assign permission directly to the user, avoiding the need to create a role.
I agree with the earlier post that you should look into og and gojoingo as well.
I'm not sure any of the current taxonomy modules are what I need
I think I may suffice with just making my own node modules and then controlling access there, instead of trying to apply taxonomy access control to every node in the system.
I could create a user group table and look it up in the node's node access function and I'd prob be ok there.
Now perhaps the more complicated part of the equation is:
Ideas?
Remember that there are lots
Remember that there are lots of pages which list nodes without ever loading them via node_load. That means lots pages that display some content you might want hidden, without ever calling your hook_access. That's why db_rewrite_sql and the node_access table exist.
What I'm trying to say is your module may have to do something in hook_rewrite_sql, too.
Thanks, good point
Hmmm, I suppose that's a problem then. I don't know much ab hook_rewrite_sql. Also the user management thing is still an issue.
That still seems crazy
So if I create a custom node type, type 'x' other modules could pull that node and circumvent the hook_access thing? That seems crazy to me.
node_access_example.module
I'm looking at the node_access_example.module, would that restrict access only to a custom node, or is that a global way of changing the access of all nodes?
Have you had a look at the
Have you had a look at the tac_lite module? I've just discovered it and am going to be trying it out shortly. I'll let you know how I get on if you like.
Regards
Patrick Nelson
=================================================================
All truth goes through three stages:
- First, it is ridiculed,
- Then it is violently opposed,
- And finally it is accepted as self-evident
success?
feedback on tac lite?
-----
Drupal ecommerce, at www.drupalecommerce.com is a new site written using language that Drupal beginners and intermediate users can understand. Quick links to "Modules."
feedback on tac lite
TAC lite is not terrible. Roles see certain taxonomy. The poblem I think though is that you still will have a million roles if you want multiple groups, even if their tax-access fits the same profile.
This is a difficult issue.
Basically I'm wanting tax control that's something like your basic subscription site (ala Basecamp style).
Basically a user registers a group (every user must belong to a group) and then he can add other users to the group. Everyone in the group sees their data but no one else.
What would really be lovely is if they could add/edit users (but could only edit users they've created).
I realize this is a difficult idea, but if it could be done drupal would become a staple for subscription sites.
I'm willing to throw some money at this if someone is interested in building this module.
Glad to hear it's not
Glad to hear it's not terrible. You may have missed that access can be granted by user, in addition to by role. Edit the user account and you will see a tac_lite tab.
TAC Lite falls short of everything you want to do. But one of it's cool features is that terms can be hidden from some users with permissions to do certain operations. So for instance if a user could only see say, 2 out of 10 terms, and that user had permission to edit user accounts, then that user could only grant other users the ability to see those 2 terms, not the other 8. This goes in the direction you want, but the reality with Drupal right now is that if you give someone ability to administer users, you essentially give them permission to do everything (because they can assign themselves any role).
good
yogadex, thanks for pointing this out. I've long thought this is a terrible security hole in Drupal and didn't understand why it was not widely publicized. it's great that your module does something about this.
-----
Drupal ecommerce, at http://www.drupalecommerce.com is a new site written using language that Drupal beginners and intermediate users can understand. Quick links to "Modules" and "Module Groupings."
the prob with tac lite and other solutions
The problem with tac lite and other solutions is that websites dont have half a dozen users, they have dozens, hundreds or thousands of users so any solution that requires micromanagement won't cut it.
Jaykali, It sounds to me
Jaykali,
It sounds to me like you want to use both the og module with either TAC or TAC-lite. The general rule is that you can't use these modules together but that's not strictly true. We use them very successfully on www.vcommunity.org.uk. The trick is knowing what you want each module to do, perhaps be willing to hack a bit and make sure you have everything mapped out in terms of content types, taxonomies and user roles.
Back to the point, the og module would let you run the multiple groups easily - permission to create new groups could be simply assigned to a user role.
As far as "every user must belong to a group", og has a nice contrib that allows you to define a mandatory group - there is also a promote contrib that allows you to change roles when someone joins any one of a number of groups that you determine.
With og, users can invite other users to the groups they belong to. Again, a little hacking and you could make this that users can physically join other users. Alternatively, you can make as many users as you want to be admins and then they can add other users anyway.
As far as private data is concerned where only the author can see it, the simplest way that I've always done this is to have a content type which by default is unpublished and then use something like the workspace or the drafts module to allow the user to see their own content. That way, they get to see all their unpublished work (they don't even know it's unpublished - only that no-one else can see it).
As far as adding other users are concerned there are also several solutions to that. The best one I think in this case would be the guestpass module which allows users to issue guestpasses to the site. Again, a bit of tweaking and you could make the guestpass never expire.
Finally, the only other alternative is to use something like plone (www.plone.org). I build sites in both and I have to say that I prefer Drupal but plone does have some pretty meaty permissioning.
PS -
I'd be interested in helping out with this.
Regards
Patrick Nelson
=================================================================
All truth goes through three stages:
- First, it is ridiculed,
- Then it is violently opposed,
- And finally it is accepted as self-evident
what's your rate
What's your rate and how long do you think it would take to create a module like I've described?
I'll contact you via your
I'll contact you via your contact tab
Regards
Patrick Nelson
=================================================================
All truth goes through three stages:
- First, it is ridiculed,
- Then it is violently opposed,
- And finally it is accepted as self-evident
plone
I'm also going to play with plone and see what it can do. I've heard good things ab it though the python part scares me.
merlin
Patrick,
nice comments.
you all know about merlin's new node access arbitrator module right?
Drupal ecommerce, at http://www.drupalecommerce.com
http://www.drupalecommerce.com/troubleshooting
http://www.drupalecommerce.com/modulegroupings
http://www.drupalecommerce.com/47vs46
http://www.drupalecommerce.com/compared
buh
node access arbitrator?
edrupalec, Yes. I've not had
edrupalec,
Yes. I've not had to use it on vcommunity - actually I set up og and TAC before merlin's module was born and haven't implemented it there as it can cause problems if installed on a site where node access permissions are already in play.
Having said that, I've played with it on a test site and it works quite well although I don't believe it's production-ready (wasn't last time I looked, but I'm willing to be corrected).
@jaykali - if your site isn't yet live, edrupalec's suggestion is definitely a good one, check it out.
Regards
Patrick Nelson
=================================================================
All truth goes through three stages:
- First, it is ridiculed,
- Then it is violently opposed,
- And finally it is accepted as self-evident
my site is not live yet
I'll try anything. So you're saying the "suggestion" that is "definately a good one" is the node arbitrator thing?
Yes, that's what I'm saying.
Yes, that's what I'm saying. This is why:
1) To do what you want to do with Drupal, the best way (IMO) is to use og module and TAC (or TAC_lite) module which all affect node access permissions
2) Running two modules that affect or control node access permissions is not recommended
3) node arbitrator is "is an experimental module API designed to allow multiple node access systems to work together" therefore I recommend we use it.
Regards
Patrick Nelson
=================================================================
All truth goes through three stages:
- First, it is ridiculed,
- Then it is violently opposed,
- And finally it is accepted as self-evident
tac_lite can be used in
tac_lite can be used in conjunction with other access control modules (I've used it with cac_lite, but those two were written to make that possible), but it's experts only terrain. You should only attempt this if you know what you're doing.
And anyone doing anything complicated with node_access should enable devel_node_access which comes in the devel module. devel_node_access includes a block which shows every node loaded and its node_access table entries. So as you are browsing your site you can see which nodes are protected and which are not. The display will make sense if you understand how node_access works.
cool
cool. thank you for pointing that out.
Patrick, thanks for letting us know your beta results with the arbitrator.
Drupal ecommerce, at http://www.drupalecommerce.com
http://www.drupalecommerce.com/troubleshooting
http://www.drupalecommerce.com/modulegroupings
http://www.drupalecommerce.com/47vs46
http://www.drupalecommerce.com/compared
I've worked out a solution
I don't have a module worked up yet, but I did work out a solution to assigning roles to users based upon the group ID of the node to be accessed.
It required:
* modification of the og_roles.module to *really* assign roles to users by group
* creation of a new table to tie roles to group ids
* modification of the user_access function in the user.module to use my new table for permissions checks
It took a few months, and NO ONE helped, but I've got it up and working. I can have an unlimited number of groups and use only 2 roles (member, admin). Which means that every user can have different roles in different groups (instead of the same roles in all groups).
If someone could help me figure out how to "modularize" the application, I'd be willing to give it a try. In particular, I need to know how to "templatize" my user_access function so that I don't directly modify the user.module.
-ron
I'd accept a patch to
I'd accept a patch to og_roles module that works as you describe, as long as it kept the original functionality too as an option (client wanted it that way).
There's no point to keeping original functionality
When you think about it, og_roles really doesn't do anything more than assign a role to a user. Since that role is not limited to any group, this is the same functionality you have without og_roles. og_roles just makes it *look* like you're assigning a role to a user in a group. So, if you want to keep that screen and that functionality, just keep og_roles.
What I did was to create a new module, og_user_roles that uses a new og_users_roles table and actually assign roles to users *limited* by group.
This new feature does not negate the existing functionality. You can still assign global roles to users (you can still even use og_roles), and those permissions will be recognized. I've just modified the permissions function so that if you have a role in a particular group, while you are in that group, you are granted all permissions for that role. When you leave the group content, the permissions of that particular group-assigned role are no longer applicable to you.
My problem, again, is that I had to modify the user.module to get all this to work, and I'd rather not make direct changes to the Drupal core. I just don't understand enough how "hooks" work to add this new permissions functionality without changing the user.module.
This should be its own project
Great functionality. I agree that this improves upon vanilla og_roles.
I'd be happy to help with this. Do you intend to get commit privileges and start a separate project?
Can you explain how this works?
What is the process? Where does one start?
Again, I don't know how to insert the additional functionality without modifying the Drupal core user.module. Doesn't that present a problem?
Perhaps starting a new
Perhaps starting a new og_roles issue and posting patches or the entire module(s) would be a good start. The community can have a look and go from there.
OK. I'll try that.
Thanks. I'll create a new og_roles issue and see where it takes me.
Issue Created - Code Uploaded
The code has been uploaded here: http://drupal.org/node/87679
Anyone who wants to try it can have at it. Let me know if you come up with a more elegant way to implement the "user_access" function changes.
Thanks!
sounds cool
I'd love to try it out. Modularizing might be tricky.
User SCOPES
I have been contemplating a similar Idea. In mine a user signs up by using a "Zipcode" lets say. It is stored in their profile. The others who have the same "Zipcode" in their profile will be able to see content that was written for (targeted by Author who selected the same zipcode when then wrote the article). Users in that Zipcode and no one else would be able to view these nodes. that is equivilant to your "Office", except in this case they are not invited.
My goal is to somehow allow users to restrict viewership to their neighbors and still have the ability to increase the scope (or distance - such as city, county, etc) so more people can read their articles. In reverse a user can limit their 'search' for "News" to a small area or a large area using the same concept. Needless to say I am talking about a LARGE user base.
I have seriously considered submitting this concept to sourceforge or other development community for group development since it incorporates alot of developers "wanted features"
Any Feedback?
og_goup_of_one
I created an og_group_of_one module that does what you are looking for.
It automatically creates a new group for each user that registers with your site. It allows you to set the default group settings, so you can set for example a different theme for all og_group_of_one created groups.
http://regx.dgswa.com/html/?q=node/3
I will get a project set up for this soon.
My personal Drupal site.
http://www.regx.dgswa.com/html/index.php