Currently there are set administrator "roles." If an organization's administrators don't fall neatly into these roles, then they end up with either too many or not enough permissions. It would be nice to be able to customize administrator roles, and determine whether that type of admin has full access, read-only access, or no access to all of the items described in the tables on the Site Administrators help page. I.e. A page to create/edit a role with radio selection to determine access for that role for each feature of the site. This would be immensely helpful for reducing clutter for administrators that don't need to see certain features and menu tabs. http://help.wildapricot.com/display/DOC/Managing+site+administrators

A big problem (and our organization has had this happen in the past) is when someone in charge gets disgruntled and deletes the account and information. Is there a way to require at least a two-fold verification process before an account and all information can be deleted...where it takes more than one administrator to ok it or a secondary authorization from the CEO/President/Manager of the organization? I feel our information and our account is uncomfortably vulnerable otherwise the way things are now. There just has to be a better way to protect accounts and the information from accidental or vindictive deletion.

Contacts/members with full administrative authority in particular, and to an extent perhaps, others with lesser administrative authority should have a wall erected between being just a normal member and acting as an administrator.

When I login as a member, I don't want to be in administrative mode. This mixes roles, and these roles must kept separate. When I want to go into administrator mode, WA must require me to explicitly request that role/mode (eg, a separate password, or some other mechanism).

I've also noticed that WA does not automatically logoff users after a period of time. In particular, for those with administrative authority, or in administrative mode, it is a security breach to allow such connections to remain open and active.

As a Wild Apricot partner we are tasked to do the following:

- setup a new WA website and launch
- migrate an existing WA website with new website designs

This feature is particularly helpful when a customer is already on Wild Apricot, in production but would like to test some new website design features or redesign the website altogether.

Currently our approach is to clone the production site with WA support, design on the clone and then move manually over to production. It would be really helpful if WA featured a way to export configuration options that can be imported into another WA website.

For starters I could see

1. Theme selection
2. Colors & Styles Configuration
3. Bulk File manager download (not just file by file)
4. Site template configuration

If you could export these settings and import them into an existing WA website and apply these changes it would really help.

Of course exporting events and related configuration settings for each event, exporting site pages between sites would also be nice.

Another approach would be to allow a "staging" feature to be available inside a site that can allow a separate website to be designed and Promoted to production, archiving site pages, overwriting configuration settings.

I realize it's a complicated ask with lots of issues, but right now WA redesigns and new configuration and experimentation is not really possible on a production WA system. You have to clone and move the results manually.

Currently for a number of gadgets, such as the directory gadget, privacy levels for information display and access are set to either admins, members, or anybody. However anybody is actually two distinct categories: contacts who have set up system user accounts to access limited parts of the system, say the forums, and members of the public who have not set up any system user accounts. By having a Contact user access level administrators would have one more level of security to filter system use access; this could be used as a measure to build trusted access for non-members (presumably prospective members) to be exposed to the organization's activities.

As a part of this proposal I would add that contacts have privacy settings in their system user profiles.

Here is an example. We are considering putting our membership directory on a public page including allowing non-members to use the personal messaging system to send messages to members. Our hobby is very eclectic so having any means of matching members interests to those of potential members is important to us. While the personal messaging system would serve as a "firewall" against spambots harassing our members it would not provide protection against a human harassing our members by sending a personal message using a false email address as the reply to address. By requiring non-member users of the system to set up a system user account before they access the personal messaging system system administrators can set up a new level of accountability for non-members using the system.

Such a level of accountability already exists for "public" members to access the forums; by making Contacts a full access level that accountability can be spread system wide.