Custom Administrator Permissions - to define new admin roles and access permissions depending on an organization needs
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
Liz
shared this idea
55 comments
-
Mary Adams
commented
Just want to emphasize that read only access comes with the ability to download the ENTIRE CONTACT DATABASE. This creates HUGE issues for our terms of service which says we won't share our contacts' data. It's impossible to police every volunteer who has access to the system. I was thrilled when WA took off the limits on the number of admins but we can't use this until the download issue is solved. I love WA. Please fix this!
-
Mary Folsom
commented
We have 42 event managers, of varying degrees of competence, and are constantly in Damage Control when they do things like update the default event email reminder template instead of their own. Our new Damage Control involves taking dozens of names off Google search results, because someone checked the "show registrants to Public" box, in contrary to our policy. We really need this function.
-
rrhrunner
commented
Add to the Membership Manager's functionality the ability to do event "check in". But not duplicate the event manager's over all functions.
In our organization the Membership Manager servers as the greeter for most of our social events and wants to take attendance electronically and do away with paper forms for check in. Along with this she would need to be able to "add registrant" for walk ins as not everyone will have RSVPd in advance. -
Randall Rensch
commented
While we, too, want to provide certain Members with very restricted access (e.g., an Event Organizer gets access to data for only their event, possibly even read-only), here's a solution to one issue mentioned here:
> to give the front desk person the ability to see if someone is a member
Apparent solution: Create a web page that lists Members. The list is based on an Advanced Search that you create. Members' preferences can be selectively set up so that a Member's option to be hidden on that list (or to hide any particular profile data) is disabled.
-
Anonymous
commented
Our organization is also seriously discussing to replace Wild apricot due to unavailability of add/edit/delete and view permissions feature.
-
Jerry G
commented
The way the permissions work now if I want to give the front desk person the ability to see if someone is a member I have to give them access to all the companies financial data, including financial reports.
This one issue is going to get Wild Apricot replaced in our organization.
-
Anonymous
commented
At least there has to be a feature to lock old months records editing. Currently everything is open and donation manager can go change any record or payment without any kind of restriction in wild Apricot system.
Donation managers are human, they can make mistakes but application should have enough control to avoid such situations.
-
Anonymous
commented
We have membership/donations managers working from multiple locations, some old donations records were modified by users. It was really hard to track who modified which receipts as our balances of previous months were out of reconciliation.
Finance Dept. raised serious concerns about our selection of membership management solution as Wild Apricot as there was no option to limit old entries modification.
It’s a mandatory feature to have option to restrict membership manager and donations Managers not to edit old payments or donations in current application.
Kindly consider this post as high priority feature request.
-
paulp575123
commented
Absolutely agree! I had someone with full administrative rights go in and monkey around with a web page. Now I have to fix it!
-
Admin
commented
Page and feature (action button) level access permissions should be available
-
Mary Guttieri
commented
I just need my donation managers to be able to edit existing contact info. They can put in NEW contacts, but they can't change info for existing contacts, which is a real problem. The donation managers see checks, etc. and have contact info.
-
TangentRW
commented
A few thoughts about delegated administrative roles:
Within each general administrative role there are specific features which involve viewing/creating/editing/deleting data on the system. Within that data I see a distinction between data that is common service data (contacts data, membership data, system settings, financial settings, system email templates) and other data, which I will refer to as content data.
Common service data would include all data that would not qualify as a specific communication or service by the organization.
Content data is the complement of common service data: it includes communicating and providing the services offered by the organization. Content data would include web pages, email blasts, forums, donations, blog entries, RSS feeds, the forthcoming store, and events.
Each feature in an administrative role allows for viewing/creating/editing/deleting data. A feature might be a single field or function (for example, a visibility setting) or a set of fields or functions (for examples, the details of an event or the details of an event registration type). Viewing the data might be a default that comes with the role, but there might be some exceptions.
This brings up what I call scope: the area of viewing and control for a (delegated) role or feature.
In the case of common service data, the scope would be limited to the categories defined within the role’s area of responsibility. For example, the scope of a delegated finance manager could limited to accounts receivable or other types of reports. A delegated group manager might be prevented from creating new groups but could edit members within the selected groups under the control of that manager.
Content data would have an additional parameter to scope: to limit the administrator’s ability to view/create/edit/delete content generated by that administrator or by other administrators. For example, a donation drive, web page, email manager, forum manager, or an event manager could be limited to viewing, creating, editing, and deleting
• just the content generated by that manager personally,
• the content generated by managers within a membership level,
• the content generated by the managers within a group,
• or have full access to all content within that role.With such granularity of permissions and a few tweaks to the existing feature sets, it would be possible to create implicit simple workflows for organization content data without having to program them in. To provide an implicit workflow to such editing, each set of data (an event, a donation drive, a web page, a forum category/forum area/forum thread, an email blast) would have a view restriction feature that could be switched between Admin, Restricted (to groups or membership levels), or Public. For example, by restricting a delegated administrator’s content to Admin only visibility means that some other administrator, who could see and edit the content, would have to authorize the set of data for a higher level of visibility. Similarly, restricting the visibility of that administrator’s content to the members of a group would allow peer review by that group (some of whom might not be administrators) before the content is made visible to full sets of members or to the public.
Implicit in such a scheme is that there always exists somewhere at least one administrator with full access to the entire administrator role. Also implicit is that the current number limits on administrators would not exist. Allocating delegated administrators could be limited to administrators who have been granted full access to a role or to full system level administrators.
For example, a full donations manager could delegate to a system user the ability to create and manage a donation drive. In setting up that drive the now delegated donation manager could be given access to a limited set of web pages at start to set up the donation. After viewing and removing the visibility restrictions on the new drive’s web page and donation settings, the full donation manager could give the delegated donation manager access to specific saved searches for sending out email blasts, as well view/edit access to the financial record keeping for that drive. Here I used donations as an example of how delegated roles might work; our primary interest is in events. In our case we have a need for an events manager role to be delegated down to the level of the event organizer, who in our case could be any or every member of our organization.
Delegating administrative roles empowers the membership, allowing them to generate the content that best serves to promote the organization. Empowering the members to self-organize their administration and the creation of content actually becomes a new service (content, if you will) that the organization can offer to its members. To borrow from a Canadian of note, the Wild Apricot medium itself would become the massage.
-
Nabeel
commented
Custom Administrator Role user permissions are very important need for organizations have multiple administrators or bundle administrators to manage membership data.
Permissions for each feature set would be ideal as in already present other applications, like
- Insert or Add new data
- Change Data or Edit
- Delete data
- View report
- View Audit Log of any entry
- Export Data
these permissions should be allowed to configured for each screen like Contacts, Members, Donation, Payment, Invoices, Membership Levels for through security access control mechanism. -
Anonymous
commented
Very important for us. We have volunteers doing certain management tasks. Some of them are not particularly tech savy. The existing roles would be giving them the ability to do a lot of damage.
-
AnnaG
commented
Event administrators should be able to see and manage event financial data but not other financial data
-
Anonymous
commented
This feature should be added for better control, it's an important requirement for our organization and most demanded missing feature during implementation of project.
-
Admin
commented
Add/Edit/Delete permissions for each screen like Members, Donation, Payment, Invoices etc. are required for proper user access permissions management as current roles have full permissions which becomes an issue, it's not easy to rely on Audit Log report to capture who deleted which record every time when you have multiple administrator (Donations Manager / Membership Manager role) users.
-
Rob
commented
I'd like an admin level of "event assistant", someone who can check people in, but cannot send out emails or change event details.
-
Paul Jakoubek
commented
In my organization, we want donation only visible to Donation Manager and not to other Managers.
-
Jamie
commented
Administrative Roles Update. Separation by Officer designation.
Secretary- Member Management. Treasurer- Financial Management - the ability to manage member invoices and payments but not change the members, membership types and information. Event- Manager- For specific events only.
