E-mail
The following sections describe permissions for the CRM system itself. They might not apply in the same ways at points for data collection from end users. For example, if someone is donating they will be shown some set of fields which are editable despite any field-level permissions which might exist.
Another special case permission is creating contacts. If all the other CRM permissions are in the CRM administration interface, then this permission needs to be in the same place. However, if any CRM permissions are in the Drupal administration >> users >> configure >> permissions page, then the 'create contact' permission would easily work as a Drupal permission.
For sake of simplicity we decided that the first version will use Drupal's permissioning scheme. This might introduce a lot of CRM related permissions of the drupal permissions page, but we suspect for our target audience this will not be the case. We will revisit this decision in a future release.
Search-based permissions on contacts (instance based permissions)
(currently in the contact module)
An effective way to add fine-grained permissions to contacts is to be able to permission search (or query) results. Establish a new permission by searching and then saving a named permission for those results. Two permissions will be created- view (name) and edit (name). In the contact module these two permissions are managed using the Drupal permissions system. Whether this should continue to be the case or not is debateable. Either way, the existing Drupal roles, configured at administer >> users >> configure >> roles, should be used to assign permissions.
Example
Assume we have n Roles: R1 ... Rn and m Search Terms: S1 ... Sm. There will also be a "default" search term (S0) which matches all the contacts. By default the adminstrator (uid = 0) will have view and edit permissions for all the contacts. The administrator will assign Users to Roles and give relevant Roles permissions to edit / view / administer the contacts that belong to that specific search term. Thus a User could potentially have permissions for multiple search terms. For efficiency sake, permissioning implementation is done at the sql level.
Implementation
For a given User, we can determine the Roles the User plays and hence the Search Terms that the User has permissions on. We then OR these search terms to form the appropriate where clause that needs to be appended to any query related to Contacts / Locations. This ensures that a User can only deal with those Contacts for which he is granted permission. We can skip the previous section if the User has admin privileges. This takes care of the various cases of retrieving Contact data ( exact match, generic search or using a join table )
Thus is our Search Terms are geographically seperated ( state = 'CA', state = 'OR' etc ) and if our User is a CA Volunteer who has permission to view / edit the S_CA Search Term, then his queries will look like the foll:
Note that if the user had admin level permissions the above query would look like:
Field-level permissions
(this feature is on hold)
(not currently in the contact module)
Every field in a contact record should be permissioned for viewing and editing by role. The roles used should be the roles set up in the Drupal configuration currently at administer >> users >> configure >> roles (the UI will probably be moved in Drupal 4.6). These field-based permissions should have a separate UI from the main Drupal permissions at administer >> users >> configure >> permissions because adding that ammount of permissions could easily overload the Drupal UI. A permissions table for these fields similar to that in the Drupal UI should be somewhere in the CRM administration pages.
For sake of simplicity we will use Drupal's permissioning model and page. The core fields will be split into small sub-groups ( name, email, phone, address etc) and permissions will be assigned to all fields of the sub-group as a unit. For extended properties permissions will be assigned at the crm_ext_property_group level. (this enables grouping of external properties and hence simplifies permissioning). For each of the sub-groups of core / extended properties, the system will expose view / edit / administer level permissions
Object based permissions
A significant number of objects within the system will follow the traditional permissioning mechanism at the object level. Thus a Role could be granted permission to create extended property groups and extended properties while another Role could be granted permission to only view extended property definitions. All objects not related directly to Contacts or Groups will follow this permissioning model.
