Skip to content

Scot McConnachie

My feedback

135 results found

  1. 50 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    19 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  2. 19 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  3. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Wishlist » API  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  4. 143 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    73 comments  ·  Wishlist » Members  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We have started analysis for this issue, and it seems that key problem is how Wild Apricot handles level changes close to renewal date. The system is currently designed to collect the full new level amount and set renewal date according to new level renewal policy. All prepaid amounts for old levels are disposed. Moreover, since no prorating occurs, the new level might be effective only for a few days.

    As a first step, we suggest to redesign how level change is working and add prorating there:

    - Level would be changed immediately, as now - Remaining portion of old membership level payment will be applied to new level - For new levels with specific renewal date (e.g. annual levels with renewals Jan 1st) apply the pro-rating settings for new applications: - Allow member to pay only a pro-rated amount of the new level fee (e.g. six months before renewal…
    An error occurred while saving the comment
    Scot McConnachie commented  · 

    Most of our memberships are monthly but we are now encouraging our members to join for longer terms, such as quarterly.

    1) I agree that we should have a button that allows renewal and a level change. When the level change options are shown, the current level should remain on the list of options; this is to allow the member to change his mind or to recover from a mistake in pressing the button in the first place.

    2) There is still a place for allowing a level change within a membership term. For example we have individual converting to bundle memberships and vice versa. While prorating and re-invoicing for this change would be desirable it should at least remain as a option for those organizations who wish to use it.

    Scot McConnachie supported this idea  · 
    An error occurred while saving the comment
    Scot McConnachie commented  · 

    Currently the option to Change level is no longer available once the invoice at the current level is issued. This proposal would allow a member to continue to change her/his/their membership level in their profile after an invoice has been issued for the next membership term.

    Depending upon how the membership organization works there could be two options with this change:

    1) Allow the member to change the membership level before the due date but after the old invoice has been issued.

    2) In addition to the situation in 1, allow the member to change level after the new membership period has begun. There might be proration options with this choice.

    The default probably should be the current situation and would be represented by neither option being selected.

  5. 6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  6. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  7. 18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
    An error occurred while saving the comment
    Scot McConnachie commented  · 

    I would also request an option to delete the Not Attending button.

    I confess that I have not observed exactly what the Not Attending button does but some event organizers will not want to see that as an option for their events because it subtly encourages casual readers of the email to simply make the easier choice of not attending. I can see why some organizers would want it but other organizers should have the option of not offering it.

    Incidentally, I could not find anything in the documentation about what the Not Attending button does. When I press it, it simply takes me to the event web page. Does it do anything else or is it part of a planned future feature?

  8. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Scot McConnachie commented  · 

    The point of this proposal is that to assign an event organizers to an event reveals that organizer's email address, which is a violation of the privacy settings for the user's profile.

    What probably should be added to this proposal is adding the still publicly obscured organizer's email address to the chain of system message replies for announcements, confirmations, etc.

    Scot McConnachie shared this idea  · 
  9. 5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  10. 74 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    28 comments  ·  Wishlist » Contacts  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  11. 24 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  12. 9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  13. 7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Wishlist » Forums  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  14. 33 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    14 comments  ·  Wishlist » Members  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  15. 20 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    13 comments  ·  Wishlist » Finances  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  16. 54 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    28 comments  ·  Wishlist » Members  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We have started analysis for this issue, and it seems that key problem is how Wild Apricot handles level changes close to renewal date. The system is currently designed to collect the full new level amount and set renewal date according to new level renewal policy. All prepaid amounts for old levels are disposed. Moreover, since no prorating occurs, the new level might be effective only for a few days.

    As a first step, we suggest to redesign how level change is working and add prorating there:

    - Level would be changed immediately, as now

    - Remaining portion of old membership level payment will be applied to new level

    - For new levels with specific renewal date (e.g. annual levels with renewals Jan 1st) apply the pro-rating settings for new applications:
    - Allow member to pay only a pro-rated amount of the new level fee (e.g. six months before renewal…

    An error occurred while saving the comment
    Scot McConnachie commented  · 

    This proposal is that when a member changes to a membership level of a longer term that the automatically generated renewal date adapts to the new membership term.

    We recently inaugurated quarterly memberships and invited our monthly members to upgrade to them. However for every member that upgraded after the monthly invoice was generated we had to manually adjust the membership renewal date on their accounts. As the system automatically emailed out renewal notices, the notices for the late upgrading members still stated the monthly renewal date rather than the new quarterly renewal date, which forced us to to reassure these members that they in fact had purchased quarterly memberships.

    Scot McConnachie supported this idea  · 
    An error occurred while saving the comment
    Scot McConnachie commented  · 

    I support this option but I recommend that this be flagged as an option when defining membership levels. Some organizations may have rules about changing membership levels that require review and approval by the organization management.

  17. 46 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Wishlist » Events  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 
  18. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie shared this idea  · 
  19. 22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    12 comments  ·  Wishlist » Contacts  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Scot McConnachie commented  · 

    I also would like to see this request and the below mentioned Boolean logic.

    We have a lot of membership levels and terms so trying to send a message to subsets of these groups is a nightmare under the current system. When searching by membership levels, for example, the search criteria should be check boxes not radio buttons.

    Scot McConnachie supported this idea  · 
  20. 146 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    73 comments  ·  Wishlist » Contacts  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Scot McConnachie supported this idea  · 

Feedback and Knowledge Base