Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm working on a temp branch, on allowing users to define multiple group-audience types, and each field can define the group membership type that is used.
http://drupalcode.org/project/og.git/shortlog/refs/heads/1263588
Comment | File | Size | Author |
---|---|---|---|
#21 | ogaudience.jpg | 3.93 KB | BruFFy |
#15 | og-membership-to-field.php_.txt | 1.75 KB | muschpusch |
#13 | og-membership-to-field.php_.txt | 1.69 KB | amitaibu |
#5 | group-audience.jpg | 48.67 KB | amitaibu |
Comments
Comment #1
Owen Barton CreditAttribution: Owen Barton commentedLooks very interesting - happy to help test it out!
Comment #2
amitaibu@Owen Barton,
I have one test failing and need to write one more, but yeah, it's already working and human testing is needed :)
Comment #3
setvik CreditAttribution: setvik commentedLooks interesting. I checked out the repository and gave the branch a try but am getting an error when I try and edit the audience field after attaching it to a group content node type:
Comment #4
amitaibu> getting an error when I try and edit the audience field after attaching it to a group content node type
I think I fixed this error
Comment #5
amitaibuI've changed the branch name to be the issue number -- 1263588
Here's the patch, but you can checkout the branch.
How to test:
1) Add a second membership type -- =admin/config/group/group-membership
2) Add more group-audience fields to a group content and set the "Membership type".
3) If you use Panels, add the new plugin under "Organic groups" and select the "Membership links" plugin, this will show you multiple registration links.
With this patch, we no longer use the field storage. All the membership info is in the OG-membership entity.
Comment #6
amitaibuHere's a 1 hour movie from Drupalcamp Spain, where I cover a use-case of -- http://www.gizra.com/content/drupalcamp-spain-sevilla
Comment #7
mh86 CreditAttribution: mh86 commentedTested a few demo use cases with the new branch and they worked for me. I'll try it with real world use cases later on.
Making use of different membership types definitely makes sense to me. From what I can see so far, several API functions and integrations (like Rules) need to be adapted to support different membership types and maybe we should have several 'og_membership' entity properties, but these changes can happen once the basic code is committed.
Comment #8
Luna Vulpo CreditAttribution: Luna Vulpo commentedGreat job. I am waiting impatiently for the results.
Comment #9
amitaibuCommitted!
Comment #10
muschpusch CreditAttribution: muschpusch commentedHm... I don't really get it. My use case: I want to different membership types:
1.) followers of a group who can't post new content
2.) members who can post content.
How can i achieve that?
Comment #11
Owen Barton CreditAttribution: Owen Barton commentedThat use case is unrelated to this issue I think, but what you describe is quite possible using the OG 7.x group roles and group permissions (you can set these globally, or delegate so that each group can set their own).
Comment #12
amitaibuOk, 10 days later, and I think I'll revert this patch :/ -- as #1342632: Deprecate OG group entity is the correct solution.
Comment #13
amitaibuWhile waiting for tests to pass with the revert, here's untested drush script to re-populate fields, based on OG membership, for the few that might have been working with -dev from the past 10 days on production (I hope there isn't...)
Comment #14
amitaibuReverted most of the code (kept the upgrade path from name => type, so if anyone already executed it, it's ok).
Expect this feature to return (only cleaner) in #1342632: Deprecate OG group entity...
Comment #15
muschpusch CreditAttribution: muschpusch commentedbaaah. Hitting me hard for using dev in production :) I reverted to 1.3 using the script (i did some changes). And i needed to add the name field to the og_member table
Comment #16
amitaibu@muschpusch, sorry about that ;)
Comment #17
mxmilkiib CreditAttribution: mxmilkiib commentedUpdating status. To confirm, this is why one can't currently restrict a user to posting content in just one group if they have creation rights in another? Will try looking at Prepopulate and hiding the form element as a temp solution for this.
Comment #18
GaëlGWhat's up with this issue? Is it still the way #1269176: Limitation of Group Audience? is supposed to be fixed one day?
Comment #19
amitaibu@GaëlG,
This issue is working in 2.x -- not on 1.x branch.
Comment #20
GaëlGOK, thank you for your answer. Then I'll try to set a custom validation handler in a form alter, as 2.x is not ready for production.
Comment #21
BruFFy CreditAttribution: BruFFy commentedDoes this give multiple audience (by contenttype) selections when creating node?
Case:
I have two (group)content types region, city.
Now when I have a region and city with the same name I can't see witch one is region or city.
Comment #22
GaëlGFor 2.x I don't know, but for 1.x you can use this hook:
Comment #23
BruFFy CreditAttribution: BruFFy commentedNot with 2.x, can't find something similar :(
Comment #24
BassistJimmyJam CreditAttribution: BassistJimmyJam commentedSince #1342632: Deprecate OG group entity has gone into 2.x, would it be possible to get this back into 1.x? I'm trying to create memberships between an entity and any subgroups of the group that the entity was created for and I want to use a different membership type so that I can tell which group is the actual "owner" of the entity and which ones it is simply "visible" to. I have some additional features to implement in the near future where I would like to be able to use different membership types and it seems like this is required to make that possible.
Comment #25
amitaibu> would it be possible to get this back into 1.x?
No.
Comment #26
TBarina CreditAttribution: TBarina commentedHi, on post #5 a patch is mentioned to allow users to join with different membership types (by means of a plungin for panels).
Has this patch been included in 7.x-2.0-beta3 or 7.x-2.x-dev?
It seems not or am I not able to use this feature?
Where can I find the patch? I don't find it in Git.
Many thanks in advance.
Tommaso
Comment #27
Renee S CreditAttribution: Renee S commentedAnybody have any idea what happened with this? I've tried adding multiple group-audience fields and it has issues loading permissions/roles at this point for the second field. I get
Warning: Invalid argument supplied for foreach() in element_children() (line 6370 of /includes/common.inc).
on the OG permissions page, and "Access Denied" on the OG roles page.
In the second group's permissions page (from the group), I get:
Notice: Undefined index: map in og_context_handler_node() (line 417 of /sites/all/modules/contrib/og/og_context/og_context.module).
Comment #28
Renee S CreditAttribution: Renee S commentedOk, this is sort of working, but to get it to work I had to create a group, add permissions and roles, add it as a reference to a group-post-type that wasn't doing double-duty, THEN add it as a second field to a different group-post-type, at which point roles/permissions worked fine. It seems it doesn't build the role-map properly otherwise.
Comment #28.0
Renee S CreditAttribution: Renee S commentedUpdated issue summary.