Access to fundraising systems is controlled by different roles in different systems. This is a cheat sheet as to what these roles allow access to.These will be in broad speaking terms to allow the idea of basic functionality granted with each role. Permissions are generally listed in CRUD (Create, Read, Update, Delete) or Y/N format.
Civicrm
These are the general user roles/permissions in Civicrm. This list is not exhaustive in terms of roles or permissions granted.
CiviCRM
Administrator
CiviCRM Admin
Donor Services
Donor Services Mgmt
Engage Direct Mail
Engage Mgmt
Fr-Tech
Civiproxy
Contacts
CRUD
CRUD
CRUD
CRUD
R
Import Contacts
Y
Y
Access Deleted Contacts
Y
Y
Groups
CRUD
CRUD
CRUD
Administer CiviCRM
Y
Y
Y
Profies
CRU
CRU
RU
CRU
Activities
RD
RD
R
RD
API Access
Y
Y
Y
Y
Y
Administer Dedupe Rules
Y
Y
Y
Merge Dupe Contacts
Y
Y
Y
Y
Contact Notes
CR
CR
CR
CR
Administer Payment Processors
Y
Message Templates
U
U
CiviEvent
CR
CR
CiviContribute
CRUD
RU
RU
D
CRUD
CiviMail
CRUD
CRUD
CiviReport
RU
R
RU
RU
CiviReport Administration
Y
Y
Y
CiviCampaign Administration
Y
Export Permissions
Y
Y
Y
Y
Comment
CRU
CRU
CRU
Comment Adminitration
Y
Y
Y
Field Administration
Y
Y
Large Donation Administration
Y
Y
Node / "content"
CRUD
CRUD
CRUD
OAuth Administration
Y
Authorize OAuth consumers in dash
Y
Y
offline2civicrm Administration
Y
offline2civicrm import
Y
Y
queue2civicrm Administration
Y
Services Administration
Y
System Administration
Y
Y
Use Admin pages
Y
Y
Taxonomy Administration
Y
Y
Thank You Administration
Y
User Administration
Y
View User Profiles
Y
WMF Audit
Y
Y
WMF Campaign Administration
Y
Y
WMF Common Configure
Y
WMF Common Queue Items
RU
RU
Superset
Role
Access Granted
Admin
Administer Superset
ChangeOwnPasswd
Common to all roles. Allows users to change their password
Data Consumer
Read data
Data Consumer with Export
Read and export data
Fundraising Core Reporting
Common to all roles. Allows DB access to read data from analytics.* DBs
MariaDB permissions are in the CRUDS (Create, Read, Update, Delete, Select) format. In these cases, we are trying to group users by functional area for what their current permissions would wrap up to. We may want to adjust roles such that they follow by permission vs user functional area.
Fundraising
Role
DB.table
CRUDS
Additional
fr-tech
civicrm.*
S
fr-tech
drupal.*
S
fr-tech
fredge.*
S
(possibly all)
fr-tech
fruec.*
S
fr-tech
geonames.*
S
fr-tech
log-civicrm.*
S
fr-tech
pending.*
S
fr-tech
smashpig.*
S
Fundraising Dev
Role
DB.table
CRUDS
Additional
fr-tech
Global
create temporary tables, file, process
fr-tech-ops
mysql.innodb_index_stats
S
fr-tech
civicrm.*
S
fr-tech-ops
civicrm.*
S
fundraising
civicrm.*
S
fundraising analytics
civicrm.*
S
fr-tech
drupal.*
S
fr-tech-ops
drupal.*
S
fundraising
drupal.*
S
fundraising analytics
drupal.*
S
fr-tech
fredge.*
S
fundraising
fredge.*
S
fundraising analytics
fredge.*
S
fr-tech
geonames.*
S
fr-tech
smashpig.*
S
fundraising analytics
smashpig.*
S
fr-tech
faulkner.*
S
fundraising
faulkner.*
S
fundraising analytics
faulkner.*
S
fr-tech
analytics.*
S
fundraising
analytics.*
S
fundraising analytics
analytics.*
CRUDS
fr-tech
dev%.*
S
fundraising
dev%.*
S
fundraising analytics
dev%.*
CRUDS
fr-tech
pgehres.*
S
fundraising
pgehres.*
S
fundraising analytics
pgehres.*
S
fundraising analytics
superset.logs
S
fr-tech
smashpig.*
S
fr-tech
silverpop.*
S
fundraising
silverpop.*
S
fundraising analytics
silverpop.*
S
TODO: dev_* databases
Some user specific databases are created where those users will have full access. This is a rarity and only on special request.
