In order to have all the requests being sent to the Salesforce API stored in unified manner we could research if it's possible to move Authenticator::getRequest() logic to separate class which would implement RequestInterface like all other requests.

Sometimes a return type is specified and other times it is not.

For example, no return type here even though it has to be a bool. https://github.com/xsolve-pl/salesforce-client/blob/master/src/Model/Account.php#L363 Btw. PHP 7 doesn't allow returning nulls when you have a return type declared.

On the other hand this has a return type, but no docblock https://github.com/xsolve-pl/salesforce-client/blob/master/src/Model/Account.php#L648

Is this by choice? I can understand no docblocks for simple methods with type declarations, but here it's pretty inconsistent.

Hello,

I'm following the documentation but I cannot make any doRequest, all I get is the following :

In Authenticator.php line 44:
                                  
  Authentication request failed.  
                                  

In Promise.php line 127:
                                                                                                                    
  Client error: `POST https://test.salesforce.com/services/oauth2/token` resulted in a `400 Bad Request` response:  
  {"error":"invalid_grant","error_description":"authentication failure"}                                            
                                                                                                                    

In RequestException.php line 113:
                                                                                                                    
  Client error: `POST https://test.salesforce.com/services/oauth2/token` resulted in a `400 Bad Request` response:  
  {"error":"invalid_grant","error_description":"authentication failure"}                                            

Here is my code :

        $client = new GuzzleAdapter(new Client([
            'base_uri' => 'https://test.salesforce.com/',
        ]));

        $securityToken = 'XXXXXX';

        $credentials = new Credentials(
            'MY_KEY',
            'MY_SECRET',
            'password',
            [
                'username' => 'MY_ACCOUNT',
                'password' => 'MY_PASSWORD'.$securityToken,
            ]
        );

        $authenticator = new Authenticator(
            $client,
            [new PasswordGrantRegenerateStrategy()]
        );

        $tokenGenerator = new TokenGenerator(
            $credentials,
            $authenticator,
            new RequestTokenStorage()
        );

        $salesforceClient = new SalesforceClient($client, $tokenGenerator, 'v37.0');

        // print_r($salesforceClient);

        $result = $salesforceClient->doRequest(new Query('SELECT Name FROM Account'));

I do not understand where the error come from, can you help me?

We should use full name "Salesforce" instead of "S" prefix in all places. We can also try to remove that part as we have namespaces which tell what's the class' context.

In https://github.com/xsolve-pl/salesforce-client/blob/master/composer.json the Guzzle lib is in the suggest section but actually it's required and without it the API client won't work at all as we don't have any other implementations of the client.

It seems to me that NotFoundException has nothing in common with AuthorizationFailedException. https://github.com/xsolve-pl/salesforce-client/blob/master/Security/Authentication/Strategy/NotFoundException.php

I guess https://github.com/xsolve-pl/salesforce-client/blob/master/Model/Address.php isn't really a standalone model which could be used by the Salesforce object repository but it's rather a value object which aggregates multiple scalars from the same context. For that I'd create separate ValueObject namespace within the Xsolve\SalesforceClient\Model\ one.

Travis CI can be configured to execute its builds on different PHP versions. As PHP7.0 slowly becomes obsolete (it's not supported since 3.12.2017 and gets only security fixes) I think we should start analysing the codebase against newer versions. Moreover, we require PHP >7.0.0 in composer.json so it would be great to have some confirmation the code works well on newer ones as well.

Link to report: https://scrutinizer-ci.com/g/xsolve-pl/salesforce-client/issues/master?selectedLabels%5B0%5D=4&orderField=path&order=asc&honorSelectedPaths=0

https://scrutinizer-ci.com/g/xsolve-pl/salesforce-client/code-structure/master/class/Xsolve%5CSalesforceClient%5CQueryBuilder%5CExpr%5CExpressionFactory

see https://scrutinizer-ci.com/g/xsolve-pl/salesforce-client/issues/master/files/src/QueryBuilder/QueryBuilder.php?selectedLabels%5B0%5D=4&orderField=path&order=asc&honorSelectedPaths=0#inspectioncomment-60883939

see https://scrutinizer-ci.com/g/xsolve-pl/salesforce-client/issues/master/files/src/QueryBuilder/QueryBuilder.php?selectedLabels%5B0%5D=4&orderField=path&order=asc&honorSelectedPaths=0#inspectioncomment-60883940

I'm getting this error after fixing the guzzle6-adapter issue earlier. Not getting this to work.

Problem 1 - php-http/guzzle6-adapter is locked to version v2.0.1 and an update of this package was not requested. - xsolve-pl/salesforce-client[1.0.0, ..., v1.0.3] require php-http/httplug ^1.1 -> satisfiable by php-http/httplug[v1.1.0]. - Conclusion: don't install php-http/httplug v1.1.0 (conflict analysis result) - Root composer.json requires xsolve-pl/salesforce-client ^1.0 -> satisfiable by xsolve-pl/salesforce-client[1.0.0, v1.0.1, v1.0.2, v1.0.3].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

No luck with composer require xsolve-pl/salesforce-client -W either

The services which link Packagist to the repository are deprecated:

This package is using the legacy GitHub service and will stop being auto-updated in early 2019. Please set up the new GitHub Hook for Packagist so that it keeps working in the future.

The repository should be updated following the Packagist documentation linked above.

After migrating to the boldare namespace all the URLs in the documentation, especially the ones for badges should be updated. Moreover, the Scrutinizer project should be migrated accordingly.