Answers.Body: <p>The National Urban League funded work to add ACLs to cases, which laid the groundwork for adding ACLs to activities.  See here: <a href="https://civicrm.stackexchange.com/a/8005/12">https://civicrm.stackexchange.com/a/8005/12</a>.  So one option would be to develop (or fund the development) of applying ACLs to activities.  I'm guessing the core team would be willing to take that on as a Paid Issue Queue item, since they did the groundwork.  This would be the most flexible arrangement.</p>
  
  <p>Additionally, CiviDesk has implemented a hook that allows extension authors to escalate permissions via an extension with a new hook, <a href="https://wiki.civicrm.org/confluence/display/CRMDOC/hook_civicrm_permission_check" rel="nofollow noreferrer">hook_civicrm_permission_check</a>.  This code has been written but at this time has not yet merged into upstream CiviCRM.  See <a href="https://issues.civicrm.org/jira/browse/CRM-19256" rel="nofollow noreferrer">CRM-19256</a> to see if that's still true now.  If you're able to QA this patch, please update the Jira ticket to say so.</p>
  
  <p>The second approach is much less work to get into everyone's hands, but the first approach would allow non-coders to define their own activity permissions.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-14T21:39:15.673Z
Answers.Text: Thanks, I'll try the hook. Quick == good, right now, as some users are being very vocal indeed about the possible catastrophic effects of trusted, confidentiality-sworn volunteers seeing each others' phone numbers. (If I seem flippant it's only because I sat and watched so many of this impressively security-conscious minority writing their passwords down).
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-15T14:13:36.740Z
Answers.Text: Well the hook seems absolutely great. I've mentioned on Jira that I'm (ahem) "testing" it and will keep them posted. Thanks, ass saved!
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-14T17:53:57.287Z
Answers.LastActivityDate: 2016-12-14T17:53:57.287Z
Answers.LastEditDate: 2017-04-13T12:53:13.207Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>Another option might be to look at using <a href="https://github.com/eileenmcnaughton/nz.co.fuzion.relatedpermissions/" rel="nofollow noreferrer">Related Permissions</a> extension. User A is a member of Team B, and has a permissioned relationship over the Team and therefore could (maybe) edit Activities that are assigned to the Team, without having access to the other people who have a relationship to the Team.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-14T21:44:31.317Z
Answers.Text: Thanks, I might come back to this but it would mean adding in the notion of assigning to teams whereas the way I've set it up we don't assign them, we just use dashboard reports to alert members of the relevant team when certain activities are scheduled. Also some activities need to be visible by multiple teams. It would mean coding anyway in order to add default team assignments to activity types... I'm hoping the hook will be sufficient!
Answers.UserDisplayName: naomi
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-12-14T20:20:13.227Z
Answers.LastActivityDate: 2016-12-14T20:20:13.227Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>The organisation I'm setting up Civi for does not assign activities to individual people but works in teams.</p>
  
  <p>For example a client might be referred to the housing team to see if they qualify for housing. This activity would be created by a caseworker and edited / completed by a (any) member of the housing team.</p>
  
  <p>This is just one example, there are also other cross-team activities.</p>
  
  <p>The only way I have been able to make this work is by giving all caseworkers edit access to all other caseworkers.</p>
  
  <p>This has not gone down at all well with the caseworkers who do not want their contact details viewable - and editable! - by so many people.</p>
  
  <p>Any advice on how I could make it possible for A to edit an unassigned activity created by B, without giving A the ability to see or edit B's contact information?</p>
  
Tags: <activities><permissions><acl>
Title: Permission to edit activities but not contacts?
ThreadText: # Permission to edit activities but not contacts?
  
  (Asked by: username_0 on 2016-12-14)
  
  The organisation I'm setting up Civi for does not assign activities to individual people but works in teams.
  
  For example a client might be referred to the housing team to see if they qualify for housing. This activity would be created by a caseworker and edited / completed by a (any) member of the housing team.
  
  This is just one example, there are also other cross-team activities.
  
  The only way I have been able to make this work is by giving all caseworkers edit access to all other caseworkers.
  
  This has not gone down at all well with the caseworkers who do not want their contact details viewable - and editable! - by so many people.
  
  Any advice on how I could make it possible for A to edit an unassigned activity created by B, without giving A the ability to see or edit B's contact information?
  
  **Tags:** activities, permissions, acl
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-12-14. Score: 1 | Accepted answer
  
  The National Urban League funded work to add ACLs to cases, which laid the groundwork for adding ACLs to activities. See here: <https://civicrm.stackexchange.com/a/8005/12>. So one option would be to develop (or fund the development) of applying ACLs to activities. I'm guessing the core team would be willing to take that on as a Paid Issue Queue item, since they did the groundwork. This would be the most flexible arrangement.
  
  Additionally, CiviDesk has implemented a hook that allows extension authors to escalate permissions via an extension with a new hook, [hook\_civicrm\_permission\_check](https://wiki.civicrm.org/confluence/display/CRMDOC/hook_civicrm_permission_check). This code has been written but at this time has not yet merged into upstream CiviCRM. See [CRM-19256](https://issues.civicrm.org/jira/browse/CRM-19256) to see if that's still true now. If you're able to QA this patch, please update the Jira ticket to say so.
  
  The second approach is much less work to get into everyone's hands, but the first approach would allow non-coders to define their own activity permissions.
  
  > **Comments:**
  > **username_0**: Thanks, I'll try the hook. Quick == good, right now, as some users are being very vocal indeed about the possible catastrophic effects of trusted, confidentiality-sworn volunteers seeing each others' phone numbers. (If I seem flippant it's only because I sat and watched so many of this impressively security-conscious minority writing their passwords down).  
  > **username_0**: Well the hook seems absolutely great. I've mentioned on Jira that I'm (ahem) "testing" it and will keep them posted. Thanks, ass saved!  
  
  ---
  
  ### Answer by username_2 on 2016-12-14. Score: 1
  
  Another option might be to look at using [Related Permissions](https://github.com/eileenmcnaughton/nz.co.fuzion.relatedpermissions/) extension. User A is a member of Team B, and has a permissioned relationship over the Team and therefore could (maybe) edit Activities that are assigned to the Team, without having access to the other people who have a relationship to the Team.
  
  > **Comments:**
  > **username_0**: Thanks, I might come back to this but it would mean adding in the notion of assigning to teams whereas the way I've set it up we don't assign them, we just use dashboard reports to alert members of the relevant team when certain activities are scheduled. Also some activities need to be visible by multiple teams. It would mean coding anyway in order to add default team assignments to activity types... I'm hoping the hook will be sufficient!  
  
  ---
  
  