Enhancements for Groups functionality
In our 2.36 update we have released Groups functionality - ability to organize members into groups - such as 'Board of Directors', 'Volunteer Committee', etc. These groups are independent of membership levels - one group can include members from different levels. These groups can be used to keep track of member participation in committees, restrict access to website pages to a particular group, or for advanced searches and emails. Seehttps://help.wildapricot.com/display/DOC/Member+groups
We are contemplating a number of possible further enhancements to this and would love to get your feedback.
Here are our initial ideas:
1) Group moderators. Group moderator is a member of group who does not not have any WA administration functionality but can add/remove members to group.
Note: To do this it will be necessary to let group moderator access the full list of members and member details.
- Should moderator be able to send mass emails to group members?
2) Administrator role with web editor access limited to particular group pages.
Current functionality allows you to setup account-wide web editors and group-specific read access to web pages. This enhancement would allow you to assign a web editor in a particular group - who would only be able to edit/create pages in that group.
- Is this the same person as group moderator in 1)?
- Should this person be able to add any functional - or only content pages?
3) Group-limited events. (And probably an admin role to add/edit group-specific events)
4) Administrator role with member record edit rights for a particular group. This can come handy if you are using groups for chapters.
5) Ability for people to apply to groups during the membership application process - with workflow to review and confirm their participation in a group.
-
gypse
commented
Would be nice, when applicable, to designate who is chair of the group, etc.
-
gypse
commented
Groups - Manage Participants -
would be nice to add a count of members in the group box
(instead of having to click save to see if you are at the right number) -
gypse
commented
Adding Restricted Pages -
Defaults to membership levels page and all options checked. Would be better to have NO OPTIONS CHECKED, since you are proactively choosing who can get in.Otherwise, 2 tabs, one for membership level and one for groups works slick.
********************************************************
Adding Discussion Forums -
Only way I see to restrict is to place as a child of a restricted web page, which is fine since you can make the parent page invisible if the only thing you want it for is the discussion forum and then use forums summary page to get to the discussion forum (so don't have to extend horizontal menu).BUT, then not sure what we're supposed to do when we edit settings for the discussion forum - are we supposed to also select member levels? are member levels ignored? I may be missing something, but seems confusing as to what we are supposed to do.
-
gypse
commented
FYI - liking the 2.36 group enhancements so far. Just about to load my database - instead of a custom field for each group, just have the group participation field now. Seems to be working slick. Will try more once my community level payment goes through and I can create multiple restricted areas.
A possible enhancement to consider for groups and orgs using horizontal menus - every restricted section you create is going to extend the horizontal menu, and make it wrap . . . so orgs with horizontal menus are going to have to think hard about how many restricted areas they want to create - especially if each area is just needing a restricted discussion forum to conduct decision making, like directors/officers, selection committees, etc.
It would be nice for horizontal menus if there was a way to just hang one "restricted access" section (in addition to the members access area) and then be able to hang the various group restricted areas off that. I haven't played yet to see if it is possible to do something with invisible pages and links - or invisible pages and the forum summary. I will try that as a work around once I can create the restricted areas.
EDIT - I did make one "visible" restricted section and assigned it to all members of groups that have restricted access sections. Then made the top "restricted" page for each group invisible. Created the appropriate pages under each section and placed a link on the visible page. End result is that there is only one "restricted access" menu item that comes up for all people that have access to one of these areas. Each of them have the appropriate links on the one page. Each can only get to the links their access allows them to. Works slick for a horizontal menu.
-
gypse
commented
They all sound good, except maybe for #4.
#1 - absolutely should be able to send emails - that is probably the number on need for the groups
#2 - probably the same person - and yes, include functional pages - could see group discussion forum or even a local chapter member directory with different info than the group directory
#4 - i don't know - if payment is at the "national level" and your have people in chapters able to edit renewal dates, etc - it could get messy. I could see it being beneficial if the payment is at the chapter level. Maybe a switch that could be set for each org?
