Answers.Body: <p>There was a similar issue reported in <a href="https://issues.civicrm.org/jira/browse/CRM-17067" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-17067</a> where inherited membership(s) not created due to permission check in getRelationship(). I have submitted the PR in the ticket itself and the reason why the PR is still not merged is because there are some ACL changes going in 4.6.9 and that will fix the remaining issues reported by Dave Jenkin in his last comment.    </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T09:47:54.730Z
Answers.Text: Thanks Monish. Your first fix was where I'd identified the problem. Putting in your fixes sorted it for us.
Answers.UserDisplayName: chriscant
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T09:49:25.400Z
Answers.Text: Can I ask that this fix be fitted to 4.4LTS pls? Should I add to the JIRA report?
Answers.UserDisplayName: chriscant
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T11:02:26.860Z
Answers.Text: Eileen is the right person to ask if we can include the changes in 4.4LTS and/or you can ask in the Jira ticket itself - https://issues.civicrm.org/jira/browse/CRM-17067
Answers.UserDisplayName: Monish Deb
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T07:55:16.220Z
Answers.LastActivityDate: 2015-09-18T07:55:16.220Z
Answers.UserDisplayName: Monish Deb
Answers.Body: <p>Assuming you have no custom code that explicitly creates the membership on the individual, your individual's membership is inherited from the organization's membership by the settings on the organization's membership type.</p>
  
  <p><strong>A change in membership type</strong> granted on the form from one that has inheritance by relationship to one that doesn't could be the culprit.</p>
  
  <p>Likewise, <strong>limiting the number of contacts who can inherit</strong> the membership, also set on the membership type, could result in this.  If you have a limit, CiviCRM may not automatically grant the membership.</p>
  
  <p>The permissions on the relationship <em>should</em> not make a difference.  The paradigm is a trade association: one employee should be allowed to manage the organization record and the other employees, but all of the employees should have the benefits of membership.  Membership inheritance is not affected by the permissioning on a relationship in stock CiviCRM.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T09:46:52.577Z
Answers.Text: Thanks Andrew. The membership type hasn't changed in ages. The problem and fix Monish identified fixed the problem.
Answers.UserDisplayName: chriscant
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T02:55:07.217Z
Answers.LastActivityDate: 2015-09-18T02:55:07.217Z
Answers.UserDisplayName: Andie Hunt
Body: <p>We have a problem that may have started after upgrading from 4.4.11 to 4.4.19 on Drupal - anyway, it's started happening fairly recently.</p>
  
  <p>We have public page that allows for a membership contribution for an individual to register/sign up and create an organisation at the same time (Employer of). Normally there's a contribution in the Organisation and a membership record in the organisation - and a membership by relationship for the individual.</p>
  
  <p>The problem is that the individual membership record is not being created now. (It can be fixed up by admin to create the relevant record).</p>
  
  <p>I've been tracing the code and I think it is a relationship permission problem.  If I remove a permission check in CRM_Contact_BAO_Relationship::getRelationship() then the right record is created. However this doesn't seem like a good fix for the problem.</p>
  
  <p>Can anyone think of a change to permissions or onbehalfof around this time which might have this effect.</p>
  
  <p>We do have some custom code in this area - which adds permission is_permission_b_a in CRM_Contribute_Form_Contribution_Confirm::processOnBehalfOrganization() - I think I've tried removing that .</p>
  
  <p>Thanks, Chris</p>
  
Tags: <civimember>
Title: onbehalfof organisation sign up problem
ThreadText: # onbehalfof organisation sign up problem
  
  (Asked by: username_0 on 2015-09-17)
  
  We have a problem that may have started after upgrading from 4.4.11 to 4.4.19 on Drupal - anyway, it's started happening fairly recently.
  
  We have public page that allows for a membership contribution for an individual to register/sign up and create an organisation at the same time (Employer of). Normally there's a contribution in the Organisation and a membership record in the organisation - and a membership by relationship for the individual.
  
  The problem is that the individual membership record is not being created now. (It can be fixed up by admin to create the relevant record).
  
  I've been tracing the code and I think it is a relationship permission problem. If I remove a permission check in CRM\_Contact\_BAO\_Relationship::getRelationship() then the right record is created. However this doesn't seem like a good fix for the problem.
  
  Can anyone think of a change to permissions or onbehalfof around this time which might have this effect.
  
  We do have some custom code in this area - which adds permission is\_permission\_b\_a in CRM\_Contribute\_Form\_Contribution\_Confirm::processOnBehalfOrganization() - I think I've tried removing that .
  
  Thanks, Chris
  
  **Tags:** civimember
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-09-18. Score: 1 | Accepted answer
  
  There was a similar issue reported in <https://issues.civicrm.org/jira/browse/CRM-17067> where inherited membership(s) not created due to permission check in getRelationship(). I have submitted the PR in the ticket itself and the reason why the PR is still not merged is because there are some ACL changes going in 4.6.9 and that will fix the remaining issues reported by Dave Jenkin in his last comment.
  
  > **Comments:**
  > **username_0**: Thanks username_1. Your first fix was where I'd identified the problem. Putting in your fixes sorted it for us.  
  > **username_0**: Can I ask that this fix be fitted to 4.4LTS pls? Should I add to the JIRA report?  
  > **username_1**: Eileen is the right person to ask if we can include the changes in 4.4LTS and/or you can ask in the Jira ticket itself - https://issues.civicrm.org/jira/browse/CRM-17067  
  
  ---
  
  ### Answer by username_2 on 2015-09-18. Score: 0
  
  Assuming you have no custom code that explicitly creates the membership on the individual, your individual's membership is inherited from the organization's membership by the settings on the organization's membership type.
  
  **A change in membership type** granted on the form from one that has inheritance by relationship to one that doesn't could be the culprit.
  
  Likewise, **limiting the number of contacts who can inherit** the membership, also set on the membership type, could result in this. If you have a limit, CiviCRM may not automatically grant the membership.
  
  The permissions on the relationship *should* not make a difference. The paradigm is a trade association: one employee should be allowed to manage the organization record and the other employees, but all of the employees should have the benefits of membership. Membership inheritance is not affected by the permissioning on a relationship in stock CiviCRM.
  
  > **Comments:**
  > **username_0**: Thanks Andrew. The membership type hasn't changed in ages. The problem and fix username_1 identified fixed the problem.  
  
  ---
  
  