Come on people. I can't believe we're the only ones that need temporary memberships or arbitrary period memberships.
There are currently only three event announcement presets for people that haven't registered yet for an event and that isn't enough for us.
We start promoting our events at least four weeks early and sometimes as much as six weeks. In the early weeks we send one email per week. In the final week we send two emails.
That means we would need between five and seven announcement presets to automate the entire process.
The number of reminder presets for people that have already registered (also currently three) is adequate for us, however.
Interesting Questions Mr. Chief Apricot. :-)
So perhaps let's refine this a bit. We often know the month of a future event but we don't have the actual date because of event location and speaker logistics. It's rare that we don't at least know the month so perhaps that's a good general assumption for all Wild Apricot users.
Given this assumption, what we really need then perhaps are three options (just to cover all bases).
Option 1: When creating the event an admin may select the exact date (as currently forced)
Option 2: When creating the event an admin may select just a month
Option 3: When creating the event an admin may select no date.
If they select an exact date, they may open the event for registration if they want to of course as it currently behaves.
If they select either of the other two options, registration gets automatically disabled as you suggested, then:
If they select a "month only" the event gets listed by month order.
If they select "no date" the event gets listed in the order the events were created.
All events without dates get listed after events with exact dates or month only dates.
Listing events in the order they were created would potentially make sense for admins that have only a general idea of the "order" of upcoming events in the calendar year but don't even really know even the month of the events yet.
March 5th event
March 28th event
May event (month only)
June 15th event
August event (month only)
No date event 1
No date event 2
How would this work? Doesn't seem to complex to program unless I'm missing some programming interaction but of course, your programmers wouldn't miss it. :-)
This is related but not quite the same IMO. I want to be able to post upcoming events with no date specified so people don't see a "fake date" and get confused. This is what I currently have to do with the current system, which is a work-around:
OK, great...glad its on the to-do list.
I think some (if not all) of my confusion is that some emails can be customized and they do NOT show up on the Settings page along with all the other emails. For example, when you go to Settings and select Default event emails, you get "generic" emails even though you may have created a set of customized emails for a specific event.
I don't know the best way to handle this from a user interface perspective but it is certainly confusing as it is.
I find it very confusing that the current system has multiple email configuration, status, eblast, manual, and automatic email pages and I often can't find the source of a system-generated email sent to me as administrator!
I'm sure part of this is just a learning curve but that doesn't mean the user interface shouldn't be improved to be as quick to learn as possible.
I want to have certain event registration types appear on the registration page to the general public (Everyone) but NOT specific Members so that those specific Members don't see registration types that they shouldn't be accidentally selecting.
There appears to be absolutely no way to accomplish this with the current work flow unless I'm missing something.
It seems an easy solution to this issue would be to add another selection on the Event registration type page. In addition to the current:
* Members only
* Member level 1
* Member level 2
There would be a new Availability selection of:
* Everyone except
* Member level 1
* Member level 2
I concur with others that the ability to create forms is pretty basic and fundamental for websites. It's something we would also expect rather than use a work-around or third-party form solutions.
There should be CC (carbon copy) and BCC (blind carbon copy) lists available anywhere an admin has the ability to send an email. Currently there is only a "To" list.
113 votesEvgeny Zaritovskiy responded
Old design proposal, not working on it yet and can be changed if we start working on it – https://drive.google.com/file/d/0B0f9kMyQqlBsZ3FQOWRiMERRNkk/view?usp=sharing
There appears to be no way to do even the simplest of Boolean searches in the Advanced search interface.
For example find all active members that are faculty, staff, or students of a university:
(Primary email ends with .edu OR Secondary email ends with .edu) AND Member status is Active
We also are looking for an immediate solution for jobs posting and would prefer a WA solution as a gadget rather than having to use a work-around and third-party solutions.
I'm not concerned with how or where a notes section gets added but only that one does.
95 votesEvgeny Zaritovskiy responded
We’re looking into this request in much broader context – we want to simplify overall management of contacts, lists, saved searches. Saved search should be perceived as smart lists and provide quick access to various contact and member groups.
Yes, I can certainly understand the "not that easy" part. Glad you agree.
The Add Search Criteria user interface in the Contacts Advanced Search is nicely organized by category and is a wide dialogue box.
The Add Search Criteria user interface in the Member Advanced Search is not organized, and is a narrow linear list of fields.
They should have the same interface.
There is currently no way to edit a saved search or even overwrite an existing search with a new version. One must open the existing search, save it (as a new search) then delete the old search of the same name.
Our admins find it very confusing and error prone to have two separately distinct sets of saved searches for Contacts and Members. There should be only one set of saved searches and they should apply to either (both) Contacts and Members.
Our admins find the separation of Contacts and Members to be confusing and non-intuitive. Most other databases we have used would have integrated these into a single database, a single user interface and a single set of menus and simply distinguished the difference some other way. One way would be to have a check box in every Contact that states whether this Contact is a Member or not for example and if so, the Member fields would apply.