-
-
Notifications
You must be signed in to change notification settings - Fork 825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRM-17867 - Api4 core patches #7725
Conversation
5e633fd
to
91f19f2
Compare
jenkins test this please |
e4adbd4
to
c6d67d1
Compare
@colemanw , for the issue of the kernel test failures, it's OK to change I used a mock-version of 99 to avoid unintentional conflicts between (a) the isolated/fake test entity and (b) the normal runtime entities. However, that was mostly theoretical/preventive, and we're not likely to get a conflict on the https://github.com/civicrm/civicrm-core/blob/master/tests/phpunit/Civi/API/KernelTest.php#L9 |
} | ||
$query->limit = $options['limit']; | ||
$query->offset = $options['offset']; | ||
$query->checkPermissions = CRM_Utils_Array::value('check_permissions', $params, FALSE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re: the failed test. I don't believe it's a problem with the hook infrastructure. Look at this:
- Here in
basic_get()
, it calls the constructor (new Api3SelectQuery()
) and then sets the checkPermissions property. - Inside the constructor, it calls
$this->query->where($this->getAclClause(self::MAIN_TABLE_ALIAS, $baoName));
. At that point,checkPermissions
still has its default value (false). - Inside
getAclClause()
, it short-circuits becausecheckPermissions
is false.
I took a stab at this with f62e540. It might need a similar patch for Api4SelectQuery.
jenkins, retest this please |
d7b3ea5
to
5062bbd
Compare
test this please |
test this please |
Talking with @colemanw today during spring coding. Giving an update this, and hence a heart beat on this patch. It is still alive, he's just had no chance to get to back to Api V4 stuff. This continues to be WIP, shouldn't get merged yet, until we know more about how ApiV4 will work and is complete -- avoiding to WAGNI core until then. Recommends to follow-up in a couple months still, leaving open until then |
Most of api4 is in an extension - these are the changes needed to core.
Jenkins re test this please |
I ran AUG's unit tests against 4.7 with this patch and couldn't see any major errors, Once tests run clean should be fine to merge |
@@ -176,8 +176,13 @@ function civicrm_api3_create_success($values = 1, $params = array(), $entity = N | |||
$values[$key]['id'] = $item[$lowercase_entity . "_id"]; | |||
} | |||
if (!empty($item['financial_type_id'])) { | |||
//4.3 legacy handling | |||
$values[$key]['contribution_type_id'] = $item['financial_type_id']; | |||
// 4.3 legacy handling - translate financial_type to contribution_type unless financial_type is explicitly specified. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@colemanw this change is what is breacking one of the syntaxConformanceTests specifically the grant one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my theory is that it is expecting that contribution_type_id should be outputted in the api array and always matches that of the financial_type_id
Fix contribution tests that failed in last run
Adding merge on pass per assessment by @seamuslee001 - yay |
@eileenmcnaughton we got a pass |
!! |
Core patches have been merged civicrm/civicrm-core#7725
On civicrm/civicrm-core#7725, a lot of changes to support APIv4 were introduced, including changes to the SelectQuery class, which now is abstract and cannot be instantiated. To fix this, the *Select classes now use the Api3SelectQuery class instead.
On civicrm/civicrm-core#7725, a lot of changes to support APIv4 were introduced, including changes to the SelectQuery class, which now is abstract and cannot be instantiated. To fix this, the *Select classes now use the Api3SelectQuery class instead.
On civicrm/civicrm-core#7725, a lot of changes to support APIv4 were introduced, including changes to the SelectQuery class, which now is abstract and cannot be instantiated. To fix this, the *Select classes now use the Api3SelectQuery class instead.
Most of api4 is in an extension - these are the changes needed to core.