Scot McConnachie
My feedback
133 results found
-
11 votesScot McConnachie
supported this idea
·
-
30 votesScot McConnachie
supported this idea
·
-
40 votes
An error occurred while saving the comment Scot McConnachie
supported this idea
·
-
14 votesScot McConnachie
supported this idea
·
-
30 votesScot McConnachie
supported this idea
·
-
19 votesScot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
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.
-
9 votesScot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
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.
-
105 votesScot McConnachie
supported this idea
·
-
45 votesScot McConnachie
supported this idea
·
-
1 voteScot McConnachie
shared this idea
·
-
13 votes
An error occurred while saving the comment Scot McConnachie
commented
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.
An error occurred while saving the comment Scot McConnachie
commented
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.
An error occurred while saving the comment Scot McConnachie
commented
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.
An error occurred while saving the comment Scot McConnachie
commented
Yes, that is the gist of the proposal. Plus some ways of limiting the number of periods this invoicing will continue.
Scot McConnachie
shared this idea
·
-
32 votesScot McConnachie
supported this idea
·
-
10 votes
An error occurred while saving the comment Scot McConnachie
commented
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.
-
41 votes
Dmitry Smirnov
responded
We are going to include it into our next year plan.
An error occurred while saving the comment Scot McConnachie
commented
5) If a registrant changes her/his/their registration status their forum subscription status would change accordingly.
Scot McConnachie
supported this idea
·
An error occurred while saving the comment Scot McConnachie
commented
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).
-
8 votesScot McConnachie
supported this idea
·
-
314 votes
Evgeny Zaritovskiy
responded
Collecting comments now.
An error occurred while saving the comment Scot McConnachie
commented
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.
Scot McConnachie
supported this idea
·
-
18 votes
An error occurred while saving the comment Scot McConnachie
commented
This is especially desirable since we do not yet have the ability to allow registration into repeated events and therefore have to duplicate the entire event in the schedule.
Many of our events are based around a core group of attendees who very much want others join them for subsequent sessions. Currently to do that we have to duplicate the event and then duplicate the registrations, or don't bother and just assume that the regulars will be in attendance.
Scot McConnachie
supported this idea
·
-
2 votes
Team Mobile
responded
Status update in case someone new will see this topic:
The section “Show registrants who want to be listed” have been added to API already.Schedule for email announcements and reminders can’t be set via API at the moment.
As a workaround, you could create a template event on the web, set the start date in the distant future and all settings you need. Then you can clone it via POST request:
api.wildapricot.org/v2/rpc{AccountId}/CloneEvent
The request body should be like this:
{“EventId”: 123456}An error occurred while saving the comment Scot McConnachie
commented
We are currently considering utilizing the ability to create events as part of a resource scheduling application. Being able to manage email options via the API is an expectation for us.
Note that it would be possible to indirectly manage email content and scheduling for events by administratively setting up events with such settings preset and then copying them, however this is not possible for two reasons:
1) There is a bug in Wild Apricot where duplicating past events behaves differently than duplicating future events. If a future event is duplicated then the event email messages and schedules are duplicated, however if a past event is duplicated then these settings are not duplicated. This is a bug because this different behavior is not documented and does no meet reasonable user expectations.
2) The API is missing a "duplicate event" call. In my opinion it should have such a call, partly for the mobile app in addition for other potential apps.
Scot McConnachie
supported this idea
·
-
50 votes
An error occurred while saving the comment Scot McConnachie
commented
Note that the comment immediately below is much simpler than the original proposal; it simply says that it should be possible to duplicate an event in the same way, regardless of whether the event is past or not. This would allow an event to be copied to serve as the basis of another event. It was moved into this proposal by an admin, presumably because its practical use had some aspects in common with the original proposal.
An error occurred while saving the comment Scot McConnachie
commented
Currently when a future event is duplicated, the event email settings are duplicated, specifically the email texts, the email distribution lists, and the schedule for releasing email x days in advance of the event. However, when the event has already happened and it is duplicated then the email schedules and distribution lists are not duplicated. At the very least this is inconsistent behavior and it is also undocumented.
The proposal is to treat copying past events the same as copying future events. For each email announcement or reminder in the source event, its distribution list and schedule of x days in advance would be copied into the duplicate event. In the case of the schedule x days in advance the new email schedules would be from x days in advance of the duplicated event's newly scheduled date-time.
By preserving consistent treatment of copying between past and future events it will also be possible to create 'template' events to help administrators standardize data inputs between different events.
Having a 'template' ability also leads to this corollary suggestion:
Add to the Events API a call for duplicating a specific event. This will enable calling such 'template' events to standardize data entry across events even if the API does not allow access to the specific email controls for an event. Duplicating the event from the API would duplicate the email settings.
I also sympathize with the proposal elsewhere to allow duplicating event registrants as well but believe that this should be an option only.
An error occurred while saving the comment Scot McConnachie
commented
Currently an event in Wild Apricot consists of a set of data fields (event title, a set of dates and times, location, description, tag field, registration form with standard and customizable fields, registration types, and customizable emails. This proposal would be to allow an administrator enter some or all of the details for an event and then to save these details as a template for the creation of complete events.
1. Any partially or fully completed event can be designated to be an event template. The template will store all properties at the time that it is created. The template will have a name and can be found on an administrator’s system list of event templates.2. When an administrator creates an event or, under a pending proposal (not by this author), adopts a member’s event submission, the administrator may select a pre-existing event template to complete or override the event’s details. The chosen template remains associated with the event.
3. Similarly when an event template is edited but not saved as a new event template type, events using that template will be updated to match the details in the edited template.
a. When source event data would be changed by changing a template, or by standardizing to a template, the system would inform the administrator what data is about to be overriden and provide a check for the administrator to proceed or not. If the administrator elects to not accept a change to an event that would have the event conform to an event template, the event would no longer be associated with the template.
i. Because of the numbers of affected events this check have a simpler option to only allowing or disallowing the change on all events using that template.
4. When event data overrides the event template, the system would inform the administrator that the event will no longer conform to the template and indicate where it no longer conforms. If the administrator signs off on the changes anyway the event is no longer associated with its template.
5. Any event using a template can be saved as an ordinary event without a template, thereby ending its assocation with its original event template.
Events are usually some of the most important content that an organization has on its website. This proposal enhances events as containers of information by providing easier, and faster means to enter and validate that content.
Scot McConnachie
supported this idea
·
-
20 votes
An error occurred while saving the comment Scot McConnachie
commented
There do exist proposals for a resource scheduler.
Instead of relying upon tags I would prefer having customizable event data fields (associated with the event, not with the registration or contact data types).
I would not discount the tag field entirely either. If there was a means of centrally managing the tags so that they could be edited en masse that would improve the use of tags as a sort of catchall.
Scot McConnachie
supported this idea
·
Scot McConnachie
shared this idea
·
Yes, with event showing up in the calendars of these social media.