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.
Per the attached screenshot.
Comment | File | Size | Author |
---|---|---|---|
#11 | 1821808-group-contributors-more-link.patch | 3.29 KB | BarisW |
#5 | Screenshot_3_26_13_10_45_AM.png | 27.56 KB | ezra-g |
commons_group_contributors.png | 62.82 KB | ezra-g |
Comments
Comment #1
ezra-g CreditAttribution: ezra-g commentedTagging for beta1.
Comment #2
japerryThere are a few pre-reqs to this issue to getting completed:
1) deciding what imagesize to use for the block (right now its using default, I think 50x50 should be used?)
2) Creating an 'organizer' role. Right now there is only Administrator Member, and this might just require us to rename the role itself.
3) Theming the views grouping fields. If you do all of the above, it'll look like this:
Comment #3
ezra-g CreditAttribution: ezra-g commentedThe 2 remaining action items:
- The title of the block should be "Group contributors"
- Group organizers are not appearing as contributors for the sample content created during a fresh install
Comment #4
japerryOkay a little more of an update on this.
1) Since default roles show up as -nothing- the view has 'contributors' as the default text. This should mean we only need to theme the administrator member role title. Other additional roles, if added, will show up correctly on the view.
2) Changed title to show what the interactive prototype has. We'll need to add counts, but that is for later. That issue is #1869066: Count of Items, Contributors to a group Views integration
3) Organizers are being assigned properly when using the web installer. This might not be true for the drush site-install command, but that should be tackled in another issue since we have a few other things that aren't working with drush si either.
Fix here
http://drupalcode.org/project/commons_groups.git/commit/b5f0569
Comment #5
ezra-g CreditAttribution: ezra-g commentedThis needs work per the attached screenshot.
Comment #6
japerryThere are a few ways to tackle this:
1) Create a view attachment that places the admin group first, then attach the rest of the roles after.
2) Make a preprocess function that takes the results and re-arranges them so that the admin group shows up first
3) Make a sort filter for og that correctly sorts groups.
* Note just a sort filter isn't good enough, because if we had a role called 'accounting', we'd end up with admin group second
* Its possible we could force the admin group to be first in the sort, but I'm pretty sure the og module wouldn't accept this as a patch.
I think for now I'm just going to go with option #1.
Comment #7
ezra-g CreditAttribution: ezra-g commentedIs there a reason sorting desc instead of asc wouldn't work assuming we are sorting on the og role name? Seems like this has the potential to simplify the implementation of that option.
Comment #8
ezra-g CreditAttribution: ezra-g commentedIn general I agree #1 sounds like a great solution .
Comment #9
japerrySo things are not looking good for a consistent order...
While there is a role filter, it doesn't work because users aren't part of an OG role. Therefore if I split the view into an attachment and the pane, the pane doesn't work because the join requires that the users have roles. here is some discussion of the problem. http://drupal.org/node/1748390
SELECT DISTINCT users.picture AS users_picture, users.uid AS uid, users.name AS users_name, users.mail AS users_mail,
og_membership_users.group_type AS og_membership_users_group_type, og_membership_users.gid AS og_membership_users_gid,
users.created AS users_created
FROM
users users
INNER JOIN og_membership og_membership_users ON users.uid = og_membership_users.etid AND og_membership_users.entity_type = 'user'
INNER JOIN og_users_roles og_users_roles_og_membership ON og_membership_users.etid = og_users_roles_og_membership.uid
WHERE (( (og_membership_users.gid = '1' ) )AND(( (users.status <> '0') )))
ORDER BY users_created DESC
LIMIT 16 OFFSET 0
Whats worse, is in bold, do you see the issue here? its not limiting the og_users_roles tables to just those roles that exist in that table and in the membership table. In other words, if a user has a role (administrator member) in another group, they will show up in this query. The result upon install of this query is this:
pic uid name mail group_type gid created_time
2 2 Jeff Noyes jeff_noyes@example.com node 1 1364283691
0 1 admin d7@blah.com node 1 1364283476
But here is the og_users_roles table:
uid rid gid group_type
1 3 6 node => this is admin for gid 6
2 3 1 node => this is Jeff for gid 1
3 3 2 node
So basically there are two issues here..
1) We don't put members in the og_users_roles table, therefore we cannot use the views filter to get members only (or non admins if we had other roles)
2) The view handler itself is broken, linking users from other groups to the query
Comment #10
BarisW CreditAttribution: BarisW commentedAnd now what? We're ten months further since the last update. Any news?
I've created an issue in OG to be able to sort on Group Roles, #2169469: Add sort on group role in views
Comment #11
BarisW CreditAttribution: BarisW commentedHere's at least a temp fix. The biggest problem with the sorting is that the group maintainers can drop of the first 16 users (and thus are not shown). The 'more' link however, does not show you all users, bug again only the first 16. This patch fixes that, by showing all users. The order is still wrong, but this could for now help as a temp fix.
Comment #12
AaronBaumanCross-posting feature request / bug report for OG which should solve this issue: #1748390: OG Roles should be attached to OG Membership entity on load; og_users_roles should have a foreign key for og_membership
Comment #13
japerryNeed to mark this as 'closed not relevant' -- we have two blocks for organizers and contributors now since like 3.2?