The group/$group_type/$gid/admin/people
page uses a View and allows changing the view/display through the og_ui_admin_people_view
variable. Unfortunately if you have multiple group types there is no way to change the view for one group type but not the other(s).
For example, I have a Node group and a custom entity type that is setup as a group as well. I haven't done this yet, but I'm also going to make them use different membership types, so that I can add new fields to a users membership to the Node group, while my custom entity type group will only use the default membership type. I would then like to add a field/column to the Admin People View for one of the new fields from that membership type.
Proposed Solutions
I can think of a couple ways to allow using a different View for different group types.
- Add additional variables, something like
og_ui_admin_people_view__$group_type
- Perhaps use a new hook/alter instead of a variable, which could make it possible to use a different view depending on the bundle of the group type or other conditions as well.
Comment | File | Size | Author |
---|---|---|---|
#1 | og-allow-separate-admin-people-view-2293303-1.patch | 2.96 KB | jojonaloha |
Comments
Comment #1
jojonaloha CreditAttribution: jojonaloha commentedAttached is a patch that uses a new hook + alter to get the view name and display to use.
Here is a sample of how I'm using it, in case that helps give some more context.
Comment #2
shushu CreditAttribution: shushu commentedThe idea of having different views per group time is good.
Currently while the value is saved in a variable, it mainly has a UI via 'admin/config/group/settings'. Any change suggested should include a proper user interface.
Considering this is settings per group type, we need to think where would be the right place to put it.
Comment #3
jojonaloha CreditAttribution: jojonaloha commented@shushu if I understand correctly, it sounds like you would rather see option 1:
That way we can maintain the existing UI for this setting, but add the new options to the UI as well. Rather then a new hook, as I added in the patch in #1.
If I have that right, I'll work on a new patch.
Comment #4
shushu CreditAttribution: shushu commentedI think having the UI to setup the view is important for the end user, and saving the values in the variable format you described can be a solution.
Looking into how `og_group_content_type` is being handled, it is being added into configuration form via `og_ui_form_node_type_form_alter`, and properly updated/deleted as required, but it seems to be done as variables, as you suggested.
Patch would be great !
Comment #5
nerdoc CreditAttribution: nerdoc as a volunteer commentedAny progress on this?