Hello,
OG User Roles looks like it almost accomplishes what I need it to do. That is, I need users in group type A to be able to post certain node types (for example, group type A would allow posts of content types Script, Image, Video), and have users in group type B to be able to post certain node types (group type B would allow content types Message, Meeting Itinerary, Event). I could make this happen by having the group admin approve users for the roles, but this is an extra step I don't want to have. My goal is to make groups easy to work in with as few roadblocks as possible, and having to be assigned the needed roles by the group admin would inhibit user interaction. Is it possible to assign a basic group role for one group type, and another basic group role for another group type?
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | og_user_roles.module.5.x-2.8.patch | 36.57 KB | somebodysysop |
Comments
Comment #1
somebodysysop commentedNo. However, it is possible to automatically assign a basic group role for one group, and another basic group role for another group. See the setting: "Allow Group Admins to define Default Basic Group Role for new group subscribers".
Comment #2
tannerjfco commentedThat's close, but no cigar. In the configuration I'm going after, group admins should not have to do anything other then approve members (if it's an approval based group) to get them in and contributing.
One thing I noticed in the option you mentioned:
"Do you wish to allow Group Admins to define a specific "basic group role" for every new subscriber to their group at the time he subscribes to the group? The role is limited to the group that he is subscribed to. This role assignment can be be removed by the groups' admin(s). The Group Admin will be able to define the default group role on edit (not creation) of the group node. Group Admin must have configure member roles permission."
Why is it only definable on edit and not creation of group node? If it were possible to define it on creation, I could simply define it in a hidden field on that group type's form, which would essentially accomplish what I need.
Thanks for the help so far!
Comment #3
somebodysysop commentedBecause the name of the variable which contains the role to assign must consist of the group nid, which we do not have until the group is created.
Comment #4
tannerjfco commentedI see. Would a workaround of some sort be possible? Maybe some code that could be put in the node-[group type name].tpl.php file that would execute on the first view of the newly created group? If something like that would be possible, I might be willing to pay a bounty, as I desperately need this for the site I'm working on. It sounds like there are a few people that also need this (see http://drupal.org/node/148462, & http://drupal.org/node/192933).
Comment #5
somebodysysop commentedThese issues are completely different from what you are requesting here, as I understand it. These issues are looking for a way to have separate OG settings per node type. Your request here is to be able to automatically assign new og subscribers to a role based upon the node type of the group.
So, for node type a, new group subscribers would automatically be given role a. For node type b, new group subscribers would automatically be given role b, etc...
Am I correct?
Comment #6
tannerjfco commentedYes. I'm basically needing the functionality, as I am aiming to have different group types that allow different types of content to be posted in them. In that sense, the issues I linked to are related, as they're different ways in which that goal might be accomplished.
Comment #7
somebodysysop commentedOK, I'm thinking on it. What kind of bounty and within what timeframe?
And, to double verify, the following functionality?:
Comment #8
tannerjfco commentedWe are hoping to have this phase of the site completed by March 31st if at all possible. I've talked to my partner on this project and we are willing to offer $100 bounty for this. Please let me know if this is feasible for you.
Regards,
Tanner Ferguson
Comment #9
somebodysysop commentedThat sounds cool. Let me think on it a minute and see what I can work out.
Comment #10
tannerjfco commentedHey, just wondering if you've worked something out on this.
Comment #11
somebodysysop commentedYes, I believe so. At least theoretically. Will post a patch in a day or so.
Comment #12
somebodysysop commentedApply the attached patch to a clean download of the 2.7 release of OGR.
In OGR Settings, you will now see this option:
Set default basic group (group limited) role for users who join groups of this type: Group?
Please try it and let me know if it does what you need it to do. Thanks!
Comment #13
tannerjfco commentedI patched my copy of OG 5.x-2.7 with the posted patch and now see the new option addded. I configured two roles to test this, and added the roles to the respective group types. Looking at the configure member roles page in the group as an admin, it shows that the new test member was added with the correct role, however the permissions don't seem to be taking- I'm unable to create content as the test user. The create content link appears in OG Details, but no content types appear in OG Details menu, and no content types appear when I click create content as the test user.
Comment #14
somebodysysop commentedThat means with respect to the requirements of this particular issue, it works.
Were you able to create content as the test user with the same OG roles before this patch (in OGR 2.7)? If yes, that means something got blew up in the mix here. Try applying the patch to a new download.
My initial testing indicates that group users do have the permissions of OGR assigned roles, and see the appropriate links to create content and also see the appropriate links under OG "Create content". I tested with the "create page" permission, so try that first: Assign that permission to ONLY an OGR role and give that role to the test user and see if he sees the create page links.
Comment #15
tannerjfco commentedI didn't get very far in configuring OG User Roles prior to this patch, as I quickly realized it didn't do exactly what I needed. I will revert to a clean download of OGR 2.7 tomorrow and see if it's working there.
edit: by tomorrow i mean today, after i sleep :P
Comment #16
somebodysysop commentedForgive me if I'm confused, but this:
Seems to contradict this from your original message:
The only requirements I see articulated in this thread, beyond the default group role feature requested, were in your original post:
To provide for the above, basic OGR configuration only requires that you:
Assuming the assigned roles have the correct permissions and group members are allowed to post to the content types in question, that's it. Everything else you see in OGR settings is optional, and depends upon whether you desire the feature provided by the setting.
As per your request, I've added the settings and feature to allow you to automatically assign a group role based upon the group's type.
So, unless there is some other requirement that you've not articulated here, or a code problem with the module itself, it seems that OGR should be doing everything you've asked for. Please let me know.
Comment #17
tannerjfco commentedI got to working on this today, and realized the issue was due to having an older version of buddylist installed. After installing the newer version of buddylist, group roles started working on the clean 2.7 version. Switched back to the patched version and the functionality you added is working as expected. The error was on my part.
Sorry for causing any confusion. You added the functionality I desired, and it appears to be working as needed. Thank you very much for you help! Expect an email via the contact form regarding payment. Thanks again for your help!
P.S. the patch you provided said it was v2.8- is that to mean that this functionality will become part of the next og user roles release?
Comment #18
somebodysysop commentedYes, I think it's a nice feature for everyone to take advantage of. And, of course, that will insure that the functionality will be preserved as the module is updated.
Thanks. This was fun.
Comment #19
somebodysysop commentedComment #20
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.