smith-carson / prosperworks-sdk Goto Github PK

Not all endpoints have all operations available. This was solved for the Webhooks endpoint as it needs some custom methods as well, but it would defeat the purpose of the magic calls happening in the library for other endpoints.

Instead, on debug mode (i.e. Config::debugLevel(DEBUG_BASIC)) we should run conservative validation rules to warn the developer the call they're trying to run is not available on the API. There are already specifications for that (on BaseEndpoint::$specs) but that's not yet used.

That's more friendly than a random 404 error with no specification on what went wrong from ProsperWorks.

This is happening with various API calls and makes the library unusable.

In CustomField, we have

$field = CRM::fieldList('customFieldDefinition', $idOrName, true);

Since it then tries to do a sizeof on that field, and this field can be an object of type BareResource, we get a fatal error.

Composer recently started throwing deprecation notices in the console, saying these violations would prevent classes to be autoloaded with Composer 2.0 onwards.

It looks like the casing of the folder name does not match the namespace.

Here is the full message from composer:

Deprecation Notice: Class ProsperWorks\Interfaces\Cache located in ./vendor/smith-carson/prosperworks-sdk/src/interfaces/Cache.php does not comply with psr-4 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/bin/composer.phar/src/Composer/Autoload/ClassMapGenerator.php:201
Deprecation Notice: Class ProsperWorks\Interfaces\Crypt located in ./vendor/smith-carson/prosperworks-sdk/src/interfaces/Crypt.php does not comply with psr-4 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///usr/bin/composer.phar/src/Composer/Autoload/ClassMapGenerator.php:201

Actually, this is hardly a performance drawback - we're doing much more complex transforms, such as on Custom Fields. The option should be to disable field translation entirely.

I'm not sure if this is a problem because of the way the API returns objects when there is only one instance of said object type but I ran into this and I only have 1 custom field defined. I did not try the existing code with multiple fields but I did come up with a fix / workaround for this.

I really dont have time to do a PR and I'm also not sure if this is the best way to fix this however in CRM.php at Line 162 you have the following code:

if ($resource == 'activityType') { //yet another API inconsistency to deal with
	$list = array_merge($list->user, $list->system);
}

$result = array_column($list, $detailed ? null : 'name', 'id');

if ($detailed && $resource == 'customFieldDefinition') {
	array_walk($result, function (&$field) {
		if (isset($field->options) && $field->options) {
			$field->options = array_column($field->options, 'name', 'id');
		}
	});
}

return $result;

The problem here is that in my particular instance the $list variable was of type ProsperWorks\Resrouces\BareResource and not Array as expected by the call to array_column within this block.

I was able to fix / work around this by changing the above block to this:

if ($resource == 'activityType') { //yet another API inconsistency to deal with
	$list = array_merge($list->user, $list->system);
}


// START NEW
if ($resource == 'customFieldDefinition') {
	if($detailed) {
		$result = [$list->id => $list];
	} else {
		$result = [$list->id => $list->name];
	}
} else {
	$result = array_column($list, $detailed ? null : 'name', 'id');
}
// END NEW


if ($detailed && $resource == 'customFieldDefinition') {
	array_walk($result, function (&$field) {
		if (isset($field->options) && $field->options) {
			$field->options = array_column($field->options, 'name', 'id');
		}
	});
}

return $result;

What do you think?

For some odd reason, the ProsperWorks API is not reliable in regards to the number of records returned on search calls. Thus, there's a hacky code that tries to get as much as possible, with a safe margin to allow us to retrieve all paged records.

We should talk with the ProsperWorks Support team about that, get it fixed somehow, and update Endpoint::search().