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

Use email address when customer Id not available #80

merged 11 commits into from Jan 15, 2019


None yet
4 participants
Copy link

davidstanley01 commented Dec 28, 2018

In #79, @miken32 reported that attempting to use an email address to create/look-up a customer was failing with a reported error of "Return value of HelpScout\Api\Customers\Customer::getId() must be of the type integer, null returned". Given the docs say that either is fine, this is an issue.

After some investigation, I found 2 issues. First, the return type for the Customer::getId() method did not allow for a possible null value. Second, when attempting to set the customer data on a conversation or a thread, we were not accounting for the possibility of only having an email address.

I updated the getId method return type to allow for a null value. Then, I updated the logic to consider email address when assigning the customer values to the Conversation and any thread that uses the HasCustomer trait. Finally, I added a convenience method to get the first email address associated with a customer.

davidstanley01 added some commits Dec 27, 2018

$emails = $this->emails->toArray();
$email = array_shift($emails);
return $email ?? null;

This comment has been minimized.


miken32 Dec 31, 2018

The toArray() method returns an array of Email objects. If that behaviour is expected, this should be return $email->getValue() ?? null;

This comment has been minimized.


davidstanley01 Jan 15, 2019

Author Contributor

@miken32 I've updated this. The ConversationTest was passing a string as an email when creating the collection to test the extract method. I'm fairly sure this is where the simply $email ?? null check came from.

After updating that test to pass an Email entry object into the collection, it became apparent what the solution should be in the Customer::getFirstEmail method.

Thanks for pointing this out.


This comment has been minimized.

Copy link

dacopavlov commented Jan 11, 2019

Guys any news about this issue, I mean when do your plan to deploy fix?
Or if there is any other way to get all conversations from given email address, please if its possible provide how-to with an example.



This comment has been minimized.

Copy link
Contributor Author

davidstanley01 commented Jan 15, 2019

@dacopavlov ​This is going to go out today once I make a change to address the first comment on that PR. My apologies for the delay.

davidstanley01 added some commits Jan 15, 2019

Add convenience methods and make setters fluent (#82)
* Add convenience methods and make setters fluent

* Add fluent setters and type-hints to customer
Merge branch 'customer-by-email' of…
…i-php into customer-by-email

* 'customer-by-email' of
  Fix getFirstEmail and update test to pass email object into collection
  Consolidate logic into trait
  Fix sniff errors
  Ensure that either customer ID or customer email are present

This comment has been minimized.

Copy link
Contributor Author

davidstanley01 commented Jan 15, 2019

Looks like this is showing the commits from #82 in here as well...


bkuhl approved these changes Jan 15, 2019

Copy link

bkuhl left a comment

Looks great!

@davidstanley01 davidstanley01 merged commit 7a484b0 into v2 Jan 15, 2019

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
continuous-integration/travis-ci/push The Travis CI build passed

@davidstanley01 davidstanley01 deleted the customer-by-email branch Jan 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment