Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ezra-g’s picture

Issue tags: +commons-7.x-3.0-beta1

Tagging for beta1.

japerry’s picture

Assigned: Unassigned » japerry
FileSize
257.45 KB

There 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:

ezra-g’s picture

The 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

japerry’s picture

Status: Active » Fixed

Okay 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

ezra-g’s picture

Status: Fixed » Needs work
FileSize
27.56 KB

This needs work per the attached screenshot.

japerry’s picture

Status: Needs work » Active

There 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.

ezra-g’s picture

* 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

Is 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.

ezra-g’s picture

In general I agree #1 sounds like a great solution .

japerry’s picture

So 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

BarisW’s picture

And 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

BarisW’s picture

Version: » 7.x-3.x-dev
Issue summary: View changes
Status: Active » Needs review
FileSize
3.29 KB

Here'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.

AaronBauman’s picture

japerry’s picture

Status: Needs review » Fixed

Need to mark this as 'closed not relevant' -- we have two blocks for organizers and contributors now since like 3.2?

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.