Table of Contents | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
...
Scenario | Condition | Outcome |
---|---|---|
Delivery order | Phone number is mandatory to close the order | Creates record using the order’s phone number |
Not delivery order but user has a phone added to his account | Phone number is not mandatory | Creates record using the user’s account phone number if it doesn’t exist already |
Not delivery order and user hasn’t added a phone to his account | Phone number is not mandatory | Doesn’t create a record |
...
Pros
Uses existing lookup record structure
Search will work with both phone numbers included in the order or in the user account
Doesn’t require phone verification
Doesn’t require migration scripts, the search will work as long as the user has made one order after the feature release
Cons
A phone number can only be associated with a single customer, which will be the first one to inform the number on the platform
There isn’t a simple way to delete the link between an user and phone number recorded in a delivery order . One possibility is allowing customer support to remove the link via the support tool if it is outdated.
Implementation Proposal
The sequence diagram below represents one possible implementation of the solution where the responsibility of managing lookup records stay in the intl-users packages.
...
Commit an order with delivery.dropoff.phoneNumber +222222
Validate record in database
Searching phone in support tool
Customer details
Validate SA market solution
...
Note |
---|
Since this is just a proof of concept, the example is not working perfectly. For example, the search bar is not showing the customer name and the phone in Customer Details page is wrong but this issues would be fixed during the development. |
Searching by phone
Result
...
Code changes
In this section are listed the changes made for this validation in intl-packages and intl-admin-app repositories.
...
The user search, either by phone or emails, depends on the pk2 value of the user record in dynamo that necessarily has to have a phone number or an email, for example:
phone number:
...
email:
...
Therefore, we can only search a customer by phone number or email, but not both. Besides this issue, another problem is the update of the phone number. Today the change would only be reflected in user.details.phoneNumber
and not in pk2
(check code below), which leads to the search by phone only working with the first number registered.
...