Yes, with event showing up in the calendars of these social media.
I am totally supportive of this idea. Since half the work seems to have already been done on the event reminders this would seem to be a fairly simple improvement to implement.
It is already possible to register for a multi-session event after the first session, so continuing to announce the availability of such sessions after the starting date would be worthwhile. Many of our events are built around a core group of people who are constantly looking to have others join them.
One option could be to allow the announcement blasts to stop if the event is fully registered, and resume if slots open up due to cancelations, but I would set these as an options only.
We have similar situation in which different membership levels have different guesting privileges. While our situation is probably more complex, the number of guests is a per month function, being able to map this ability into events would still be useful to us.
We ran into this recently as well, as we have been starting to use the events system more.
Furthermore our accounting meeting for the month is after the first so, for non-electronic payments, the records are not updated at the beginning of the month. The system will show an account that is in arrears even though we have received payment. That means that 40% of our membership could be in this state for as long as two weeks.
It is not reasonable to expect our staff to update the records manually to active every month.
112 votesCollecting comments · 46 comments · Wishlist » Account administration · Flag idea as inappropriate… · Admin →
A few thoughts about delegated administrative roles:
Within each general administrative role there are specific features which involve viewing/creating/editing/deleting data on the system. Within that data I see a distinction between data that is common service data (contacts data, membership data, system settings, financial settings, system email templates) and other data, which I will refer to as content data.
Common service data would include all data that would not qualify as a specific communication or service by the organization.
Content data is the complement of common service data: it includes communicating and providing the services offered by the organization. Content data would include web pages, email blasts, forums, donations, blog entries, RSS feeds, the forthcoming store, and events.
Each feature in an administrative role allows for viewing/creating/editing/deleting data. A feature might be a single field or function (for example, a visibility setting) or a set of fields or functions (for examples, the details of an event or the details of an event registration type). Viewing the data might be a default that comes with the role, but there might be some exceptions.
This brings up what I call scope: the area of viewing and control for a (delegated) role or feature.
In the case of common service data, the scope would be limited to the categories defined within the role’s area of responsibility. For example, the scope of a delegated finance manager could limited to accounts receivable or other types of reports. A delegated group manager might be prevented from creating new groups but could edit members within the selected groups under the control of that manager.
Content data would have an additional parameter to scope: to limit the administrator’s ability to view/create/edit/delete content generated by that administrator or by other administrators. For example, a donation drive, web page, email manager, forum manager, or an event manager could be limited to viewing, creating, editing, and deleting
• just the content generated by that manager personally,
• the content generated by managers within a membership level,
• the content generated by the managers within a group,
• or have full access to all content within that role.
With such granularity of permissions and a few tweaks to the existing feature sets, it would be possible to create implicit simple workflows for organization content data without having to program them in. To provide an implicit workflow to such editing, each set of data (an event, a donation drive, a web page, a forum category/forum area/forum thread, an email blast) would have a view restriction feature that could be switched between Admin, Restricted (to groups or membership levels), or Public. For example, by restricting a delegated administrator’s content to Admin only visibility means that some other administrator, who could see and edit the content, would have to authorize the set of data for a higher level of visibility. Similarly, restricting the visibility of that administrator’s content to the members of a group would allow peer review by that group (some of whom might not be administrators) before the content is made visible to full sets of members or to the public.
Implicit in such a scheme is that there always exists somewhere at least one administrator with full access to the entire administrator role. Also implicit is that the current number limits on administrators would not exist. Allocating delegated administrators could be limited to administrators who have been granted full access to a role or to full system level administrators.
For example, a full donations manager could delegate to a system user the ability to create and manage a donation drive. In setting up that drive the now delegated donation manager could be given access to a limited set of web pages at start to set up the donation. After viewing and removing the visibility restrictions on the new drive’s web page and donation settings, the full donation manager could give the delegated donation manager access to specific saved searches for sending out email blasts, as well view/edit access to the financial record keeping for that drive. Here I used donations as an example of how delegated roles might work; our primary interest is in events. In our case we have a need for an events manager role to be delegated down to the level of the event organizer, who in our case could be any or every member of our organization.
Delegating administrative roles empowers the membership, allowing them to generate the content that best serves to promote the organization. Empowering the members to self-organize their administration and the creation of content actually becomes a new service (content, if you will) that the organization can offer to its members. To borrow from a Canadian of note, the Wild Apricot medium itself would become the massage.
I also agree that the existing limits on the number of administrators are too few in number but, if this number were increased, too many admins would have too much power. One question that I will ask, and for which in fairness I don’t expect Wild Apricot to answer publicly, is does Wild Apricot actually need a limit on the number of administrators when there already exists another parameter, the number of contacts, for moving an account up to the next pricing tier?
For an organization to grow organically it needs to rely upon its members’ contributions from below and that means empowering the members with some of the powers currently held by system administrators. The lesser powers could be assigned to individuals, to groups, or to membership levels. In our case we would want essentially all of our members to have the power to create most details of an event and for some trusted members we probably could let them create all of the details of an event.
I also point out that limits on the number of people with administrative authority is affecting how users come up with proposals on the Wishlist. For example the current proposal for allowing members to create their own events is at least partly an attempt to circumvent limits that were placed on the number of administrators.
Some organizations will want to charge interest on past due membership bills. This is commonly 1% to 1.5 % per month past due.
Having this interest automatically calculated into past due invoices would be a useful feature.
Due to a failure to understand how the current system works I am now having to go back and retroactively bill a number of our members who failed to pay their earlier bills and therefore were never invoiced for their later bills. They are not going to be happy and I am probably going to have to cut deals in some cases.
I should add that this is a pretty basic function of many membership organizations, including several golf clubs and athletic clubs that I have been a member of. Opting out is a process that is not defined by the member's decision simply not to pay.
I argue that this function is more essential than is suggested by the lack of attention that this proposal is receiving from other wishlist viewers. Self-selection may be at play here: organizations that have this function as a requirement may not be using Wild Apricot because this opt out function was not found during their evaluation of the software.
A couple more comments:
1) Some organizations might allow partial payments on outstanding invoices as part of a settlement plan.
2) Some organizations might want the actual "opt out" process to be automated within Wild Apricot. One way to do this would be to add a toggle to a membership level that would allow the organization to state its formal opt out language and allow the member to push a button indicating that the member is exercising his/her/their right to depart the organization. Depending on the organization's rules the result of pressing the opt out button could be "hard" or "soft". The "hard" result would be that the membership is immediately suspended by the member's own action. The "soft" result would handle situations where the organization's rules or contracts do not allow an immediate departure by the member, such as when confirmation by a membership committee or a secretary is required. In the "soft" opt out case the membership account would be flagged as requesting a suspension, an administrator would be notified of the suspension request, an administrator would be required to actually suspend the account, and, upon suspending the account, a notice of suspension could be sent to either the now former member or other administrators. This "soft" approach would allow an alternate means to communicate a requested opt out rather than using formal mail, email, or a telephone call.
Yes, that is the gist of the proposal. Plus some ways of limiting the number of periods this invoicing will continue.
For what it is worth, our organization uses the term "Group Host" for a bundle administrator but obviously this would not be universally applicable, nor it is supported on the system itself.
It would be nice if Wild Apricot allowed mapping organization specific terms for certain system terms.
5) If a registrant changes her/his/their registration status their forum subscription status would change accordingly.
This proposal is to provide a degree of integration between events and forums.
When an event is created include an option to create a forum thread associated with that event.
1) A hyperlink to the forum would become a part of the event's page or embedded in the event's description.
2) The event organizer would be subscribed to the forum as a moderator.
3) Subject to the visibility of the forum thread, registrants to the event would be subscribed to the forum. If the forum is visible to the public then a setting would allow either all attendees to be subscribed to the forum or the subscription could be limited to exclude non-members, members of particular levels, and/or guests. If the forum has less visibility than public then those registrants outside the event's visibility would be automatically excluded from the forum but the options would remain to exclude those registrants who are inside the forum's visibility.
3) If the event is rescheduled then the forum would receive notification of the new date and its header would indicate the rescheduled date and update its header accordingly.
4) If the event is deleted (since 'canceled' is not currently an event state, which come to think of it, it should be) then the forum would receive notification of the 'cancelation' and its header would be updated accordingly.
Most of our events are organized at the grass roots rather than serve as formal occasions. Discussion and participation among the registrants actually adds to the content of the event, to the sense of community among our members, and, when posted on a publicly visible forum, will greatly serve to excite prospective members toward joining our organization (especially when listserv makes the forums themselves vital).
Please review results of our analysis and design:
Post your comments/ideas right here. Until we see major disapproval, this is what we will develop in one of future releases.
This remains a high priority for us as well. The difference between responding to a forum notification and responding to an email thread in an email client is the difference between night and day.
We are having to use clumsy email threads (which is a two or three step process, since doing this means getting everyone's permission to disclose their email address to everyone else) to maintain communications and organizing within our organization. We have been pushing the forums recently but they remain pretty dead; the action is in the emails.
Just putting my two cents in on the need for this as well.
Every time we have had a new web developer offer his services for the group he has put in forums, the forums have died, and we have gone back to using Yahoo! Groups listservs. This has happened three times now. After this latest failure we may be looking at Meetup. To maintain interest in our organization we need push content where the end user can decide the terms of his participation. If the content is not in front of him in his email notification he will not be sufficiently intrigued to participate in the discussion; he also usually won't participate if he can't respond by hitting the reply button.
Collecting comments now.
I would like to see two choices for this feature:
1) Each session accepts an entirely new set of registrants.
2) Each session is open to new registrants but carries over the registrants from previous sessions.
A number of our events are organized around of group of core attendees who make the event viable but also very much want others to join them, which is why we would like the second option above.