Answers.Body: <p>you seem to me mixing two related but different concepts:</p>
  
  <ul>
  <li>the REST API, that's an interface to connect to Civi, mostly from external servers (eg another application). In principle, the api_keys and server key shouldn't be visible to the end user but stored in a configuration setting somewhere.</li>
  <li>the ajax API, that's how a user interact with civicrm to avoid to reload the page completely. This one doesn't need the api_key, as it relies on the user authentication to know what is allowed</li>
  </ul>
  
  <p>In both case, it's not possible to bypass the permissions from an external call directly, it would defy the purpose of having a permission system in the first place ;)</p>
  
  <p>What I would suggest you to do is to write a simple civicrm extension that offers a "member.resign" API and a new "quiter" permission (name to be improved ;) and configure the api so it's only the quiters that can resign.</p>
  
  <p>your api can then call the apis to remove the relationship or whatever else you want to do, and can have the skip_permissions parameter</p>
  
  <p>Then you simply have to grant that permissions to the roles you want in drupal and call your new api CRM.api3('member','resign', {...}) and voila</p>
  
  <p>As an aside, I'm not a lawyer and I don't want to speculate what you do with your contacts that resign, but marking them as deceased is likely to be considered illegal in most jurisdictions ;) </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-28T15:38:49.843Z
Answers.Text: Especially since I do not know a lot of deceased people who can actively resign......
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-28T15:57:41.490Z
Answers.Text: well, the one that resign could have his life status changed between the time he clicks on the "resign" button and the time the ajax call hits the server...
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-28T17:13:52.243Z
Answers.Text: true enough, but almost as likely as us drinking warm beer?
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-28T21:06:04.090Z
Answers.Text: It's about AJAX API than, since it's all supposed to be happened within same domain. And it requires higher permissions level than seems to be logical: now it tells, that  ""API permission check failed for RelationshipType\/getlist call; insufficient permission: require administer CiviCRM", but I'm not sure "administer CiviCRM" should be granted to anyone.
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-29T18:54:28.593Z
Answers.Text: It, so to say, "cured itself" so no additional extensions was needed.
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-28T13:48:21.400Z
Answers.LastActivityDate: 2016-01-28T15:56:40.210Z
Answers.LastEditDate: 2016-01-28T15:56:40.210Z
Answers.UserDisplayName: Xavier
Body: <p>Is it possible to skip api key check at Relationships delete? We'd like to create one-click link for altering Contact, where users of certain <strong>Drupal Role</strong> should be able to click "Resign" link and all magic happens behind the scenes. Since there are a lot (really) users of acting role, playing with individual user api key(s), described here <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/REST+interface#RESTinterface-CreatingAPIkeysforusers" rel="nofollow">http://wiki.civicrm.org/confluence/display/CRMDOC/REST+interface#RESTinterface-CreatingAPIkeysforusers</a> ,  doesn't sound like a good idea. So, are there something like <strong>"skip_key_check"</strong> for such a cases? Here's a piece of code currently being used:</p>
  
  <pre><code>CRM.api3('Contact', 'create', {
    "contact_type": "Individual",
    "id": key,
    "is_deceased": 1,
    "deceased_date":yestrDate,
        "custom_197": 0,
      // Relationships part - this is here  api key is being asked
      'api.Relationship.create': { 
         "id": value.rel_ID , 
         "contact_id_a" : value.cont_A, 
         "contact_id_b" : value.cont_B,   
         "relationship_type_id" : value.relationship_type_ID,  
         "end_date": yestrDate,
          "is_active": 0
          // Would be nice to have "skip_permissions_check": 1, here
       },
  </code></pre>
  
Tags: <api><relationships><developer>
Title: Overcome API KEY request at Relationship edit / delete for users of certain Drupal Role
ThreadText: # Overcome API KEY request at Relationship edit / delete for users of certain Drupal Role
  
  (Asked by: username_0 on 2016-01-27)
  
  Is it possible to skip api key check at Relationships delete? We'd like to create one-click link for altering Contact, where users of certain Drupal Role should be able to click "Resign" link and all magic happens behind the scenes. Since there are a lot (really) users of acting role, playing with individual user api key(s), described here http://wiki.civicrm.org/confluence/display/CRMDOC/REST+interface#RESTinterface-CreatingAPIkeysforusers ,  doesn't sound like a good idea. So, are there something like "skip_key_check" for such a cases? Here's a piece of code currently being used:
  CRM.api3('Contact', 'create', {
    "contact_type": "Individual",
    "id": key,
    "is_deceased": 1,
    "deceased_date":yestrDate,
        "custom_197": 0,
      // Relationships part - this is here  api key is being asked
      'api.Relationship.create': { 
         "id": value.rel_ID , 
         "contact_id_a" : value.cont_A, 
         "contact_id_b" : value.cont_B,   
         "relationship_type_id" : value.relationship_type_ID,  
         "end_date": yestrDate,
          "is_active": 0
          // Would be nice to have "skip_permissions_check": 1, here
       },
  
  **Tags:** api, relationships, developer
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-01-28. Score: 3 | Accepted answer
  
  you seem to me mixing two related but different concepts:
  
  * the REST API, that's an interface to connect to Civi, mostly from external servers (eg another application). In principle, the api\_keys and server key shouldn't be visible to the end user but stored in a configuration setting somewhere.
  * the ajax API, that's how a user interact with civicrm to avoid to reload the page completely. This one doesn't need the api\_key, as it relies on the user authentication to know what is allowed
  
  In both case, it's not possible to bypass the permissions from an external call directly, it would defy the purpose of having a permission system in the first place ;)
  
  What I would suggest you to do is to write a simple civicrm extension that offers a "member.resign" API and a new "quiter" permission (name to be improved ;) and configure the api so it's only the quiters that can resign.
  
  your api can then call the apis to remove the relationship or whatever else you want to do, and can have the skip\_permissions parameter
  
  Then you simply have to grant that permissions to the roles you want in drupal and call your new api CRM.api3('member','resign', {...}) and voila
  
  As an aside, I'm not a lawyer and I don't want to speculate what you do with your contacts that resign, but marking them as deceased is likely to be considered illegal in most jurisdictions ;)
  
  > **Comments:**
  > **username_2**: Especially since I do not know a lot of deceased people who can actively resign......  
  > **username_1**: well, the one that resign could have his life status changed between the time he clicks on the "resign" button and the time the ajax call hits the server...  
  > **username_2**: true enough, but almost as likely as us drinking warm beer?  
  > **username_0**: It's about AJAX API than, since it's all supposed to be happened within same domain. And it requires higher permissions level than seems to be logical: now it tells, that  ""API permission check failed for RelationshipType\/getlist call; insufficient permission: require administer CiviCRM", but I'm not sure "administer CiviCRM" should be granted to anyone.  
  > **username_0**: It, so to say, "cured itself" so no additional extensions was needed.  
  
  ---
  
  