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

I have a box on each page with links to other pages, and currently the options for automatic links in this box are:

Of course, I can add links manually.

Often, however, I would like to be able to add automatic links to the other child pages of the parent of the currently displayed page (for instance, under "Members Only" parent, I might have a half dozen child pages, and would like to provide automatic links to these pages in my little helpful box).

Can we have an option "Subpages of Parent of Currently Displayed Page"? This would be really nice.

Thank you,

Susan

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.