We would like to be able to specify individual members (rather than administrative roles) to receive specific system-generated emails (rather than ALL emails for membership, or ALL emails for events).

The system generates a lot of emails. For instance, there are initiation emails for membership sign-up and renewal; completion emails for membership sign-up and renewal; reminder emails for memberships that are expiring or have lapsed; and so on for events.

We have volunteers who work on membership and events who shouldn't have administrator access, but who should be able to get emails when someone signs up for a specific event, for instance.

And we have administrators who are incredibly frustrated because they're bombarded with emails that are basically irrelevant for them.

We want to be able to say that one specific member AND/OR one specific administrative role should receive a specific system-generated email, such as membership renewals or event sign-up for a specific event.

Really granular at the system-generated-email level as well as at the membership level.

When a member opts to change membership level the system automatically generates an invoice.

However if the member sends in a cheque so that one of our admin staff does the membership level change, no invoices are generated automatically.

We have a stripped down free member level that we hope encourages people to become paid members, however, the workflow as it stands now makes it very easy for our admin people to just miss the invoice step so that the member will never be charged the new rate.

I'd like to see invoices automatically generated for membership level changes (if there is a difference in price of course). At the very least, please put a "Manual Invoice" button somewhere in the workflow so that our admins are reminded that it's not an automatic process

Regards
Ian
worthing and adur chamber of commerce
www.worthingandadurchamber.co.uk

From what I've read so far through the apps we are not able to create new searches or modify existing searches that have been saved through the desktop version of WA. Could there possibly be a way to add a checkbox on the full version of WA searches to show only those searches in the app? We have a lot of internal searches that don't necessarily need to be included on the app, but it would be nice to be able to reduce the number of searches in the app list to only those that are deemed necessary for our membership administrators.

Thanks.

Larry

We would like to have our members link to outside web sites (for example to access journal article content), using the WA login. The easiest way to do this is using signed linking, which there is no support for in WA. This could also provide a simple mechanism to provide Single Sign-on support using the WA login.

For example, WA should be able to create a link such as:

<a href="pathInfo?originator=originator&identity=identity&timestamp=timestamp&token=signature">

Where:

• pathInfo - the destination of the link

• originator - the name of the service generating the signed link. This would be specified in the link settings.

• identity - the identity to which the user will be authenticated. E.g. the identity of the society or the user. (perhaps to be specified by the editor setting up the link)

• timestamp - the timestamp for the signed link, the date and time at which the link will expire. (to specify how long the link should remain valid after creation)

• signature – an MD5 checksum made up of the parameters, the pathInfo, plus a secret pass phrase.

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