For sites that use the "Payments Only" setting for SSL and a custom domain, WA still allows users to access the non-payment pages using HTTPS. That seems convienient, but there are side effects to allowing HTTPS access to an HTTP page. First, if a user does try to access a non-payment page with HTTPS, they will get a browser certificate mis-match warning. As you know, the warning that modern browsers display can be quite scary to the average user. I think you will find this issue to be more common than you think, such as a new site where the site owner has moved from an older all https site to WA and used custom page urls on their key pages. Or hand typed URLs. The second issue this would solve is with Google Webmaster Tools. WMT searches sites that have certificate mis-matches (like my three WA sites) and emails the admin about once a month to warn them about the cert mis-match. This could cause concern with some admins that don;t understand that the mis-match is legitimate and expected. So I am suggesting that when a site is using the "Payments Only" SSL setting, any HTTPS requests be redirected (with .htaccess?) to HTTP. This is really only needed for custom domains, but wouldn't hurt for non-custom domains. Thank you WA for considering this enhancement. Others please comment if you agree.

When sending out automated emails WA doesn't include a cc list in either the email header or the email body. For newer clubs or clubs that distribute administrative functions widely among volunteers, this means that when an email goes out, the (indirect) recipients don't necessarily know who else is seeing the email. And that means unnecessary FYI emails get sent after the fact.

Would it be easy to add a cc list to the bottom of the system generated emails that lists the adminstrative recipients? (by name rather than by email) Perhaps this should be an option, as some clubs may have externally managed distribution lists, which would render this option less than useful to them.

We must migrated to WA and the one thing I couldn't do which would be nice would be to import email subscription options from our old system. The import function didn't allow me to select the Subscription field even though it's a field that can be exported.

This was my work around. I created groups that matched each of our subscription options and imported to them. I then created saved queries that included anyone subscribed to that option OR anyone in that group to continue sending to the same people. The problem is people who want to unsubscribe can't do it because they received the email because I had them in a group. I'll be sending emails to those in the group but not subscribed reminding them to re-subscribe and will eventually drop the group but it's creating additional work.

There is a field called Notes that is an internal use field. This field is "hidden" in the sense that is does NOT show up in the Contacts or Members fields lists.

This causes confusion because upon import, the import program will attempt to match an imported field name of Notes to this internal use field called Notes. This causes confusion because the admin doing the import will not remember creating a Notes field (because they didn't) and won't see it in the Fields lists (because it isn't there).

I would HIGHLY recommend you either add this field to the Contacts fields as an internal use field just like the other internal use fields that are there and are required OR you take this field out of the import routine.

I recommend the first solutions.

Thanks

Can the description of a column be moved above it on a form? Right now, on a registration form, I can add a description, but it shows up BELOW the textbox/radio buttons/checkboxes/etc on the form. This is really confusing on the form. I would like the description to show up at the top.

For example, I have a column called "Volunteer" where I am asking when my member can volunteer to help out. This is a required multiple choice column that has 9 options. But the description of this column doesn't show up until after all the choices are listed. It would like a way to place this description at the top of the list of choices, so the user knows what they are choosing.

We'd love to be able to send membership system emails to different recipients for different areas of membership.

For instance, we have two categories of membership: Regular and Associate (service providers). Our Director of Membership handles regular members, and our Director of Associate Membership handles Associate Members.

Currently, all membership system emails go to one recipient (or one set of recipients). This means that either

1. One of the Directors gets all membership emails and must forward the relevant ones to the other director, or




2. All membership-related emails go to both Directors and they have to delete the ones they're not involved in.

It would be wonderful to have an additional option for the Associate level and the Regular levels, so each Director gets only the ones she needs.

We would like to be able to add new lists to the database, in particular to manage our library and our newsletters. Being able to create a table of relevant fields, including the ability to add records to a table of related events, and tie each record back to the member list would be very helpful. For the library, a list of books tied to a list of checkouts/returns, for the newsletters a list of available newsletters with a count of download attempts. I'm sure there are other equally useful options for new lists for other users, the point being that the ability to add a new list should be open such that the user can create and manage a new list for their own internal needs, not being preconceived for any particular or limited purpose. This would entail the addition of a generic gadget to access fields and add/edit/delete records from a web page.

Event receipts

Receipts can only be set up to include members addresses. Most of our paid registrations are non-members so when they receive a receipt it doesn’t have their address on it.

I know I can get around this by adding address fields to the common fields in settings but for most of our unpaid events the address is not necessary and only makes the registration process unnecessarily longer. Also when we get our VIPs to register for free at our events it is sometimes inappropriate and certainly unnecessary to ask for an address.

Is there any way around this? – if possible develop a tax receipt template set up specifically for event registrations without the address fields.