Closed Bug 969063 Opened 10 years ago Closed 10 years ago

Functional areas don't show members in /admin

Categories

(Participation Infrastructure :: Phonebook, defect)

2014-02.2
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: hoosteeno, Assigned: dpoirier)

References

Details

(Whiteboard: [kb=1265890] )

Steps to replicate:

1. Visit a functional area group in /admin, one that has members (for example, https://mozillians.allizom.org/admin/groups/group/8/)
2. Look for members at the bottom of the screen

Expected:
Members will show up like they do in other groups, such as https://mozillians.allizom.org/admin/groups/group/270/

Actual:
No members show up
Assignee: nobody → dpoirier
Status: NEW → ASSIGNED
Whiteboard: [kb=1265890]
See Also: → 968988
Additional debugging information: 

Groups whose member count is identical to their vouched member count do not display this bug.
Preferred fix for this bug and probably for 968988: Make it OK for groups to contain unvouched users.
Pull request for this and 968988: https://github.com/mozilla/mozillians/pull/804
Commits pushed to master at https://github.com/mozilla/mozillians

https://github.com/mozilla/mozillians/commit/5efb9ae9dfa43690e79259b147da4bd943eeb205
[Fix bug 969063][Fix bug 968988] Fix group membership admin for unvouched members

autocomplete_light was raising validation errors because its
autocomplete field for members on the groupmembership model
was limited to vouched members but some groups have unvouched
members.

Modified the admin for group memberships to use an autocomplete
field that accepts any user profile.

https://github.com/mozilla/mozillians/commit/516c67d7b734fae3260d35aa072fa9db87587016
Merge pull request #804 from caktus/969063-968988-admin-unvouched-members

[Fix bug 969063][Fix bug 968988] Fix group membership admin for unvouche...
Version: other → next
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
This is fixed on stage, functional areas show members in /admin

There is a problem though with the selected approach: 

If a group is big, like webdev or sf-momument, asking for the group page will fail with a timeout. This is because the admin panel renders a page with the group details along with all its members and that takes way too long. I'm going to push this to production as a temporary solution, as this works for most of the functional areas and groups, but I filed bug 970806 to fix this.
Status: RESOLVED → VERIFIED
Version: next → 2014-02.2
You need to log in before you can comment on or make changes to this bug.