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

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.