Open bohdan-vorona opened 1 year ago
@samdark Applied all the requests.
Received this while testing.
Not sure if related to the app being a draft?
Might have been related because i was requesting from localhost:30000
and then it redirected to shipwise.ngrok.io
- ignore for now.
@cgsmith For the moment, please try to use my app credentials:
'shopify' => [
/**
* Visit https://partners.shopify.com/ -> Apps -> Your App -> Overview -> Client credentials
*/
'client_id' => '8e317f58a84c1e14d07c64e6a8e4133d',
'client_secret' => '4437437bb4f1eaad2ee8d339922d338d',
/**
* You can set `https://shipwise.ngrok.io` to test it locally.
* Otherwise, if leave the default value, the current server's domain name will be used automatically.
*/
'override_redirect_domain' => 'https://shipwise.ngrok.io',
],
I will write my app state a bit later.
@cgsmith
Might have been related because i was requesting from localhost:30000 and then it redirected to shipwise.ngrok.io - ignore for now.
Yes, probably this is the reason. Anyway my app state:
Ok I have that as well.
@bohdan-vorona
#1001
as an order number)order/refund
?
Can you explain why we are using a cron for creating the queued items? Is it better just to queue once a webhook is received?
It also looks like Shopify has some built in notifications for if webhooks are failing. This is good because not all ecommerce platforms have this. Do you think it is better to just handle webhooks received from Shopify synchronously? If we fail at processing Shopify will provide some insights into failing webhooks. @samdark or @cebe curious on your thoughts on this specifically. Here is an example of the Shopify app dashboard:
ecommerce-platforms.md
if neededFeel free to add others! I'll keep this list updated.
@cgsmith Thanks for your response
UUID is correct on the order but the order number should match the Shopify Name (usually starts with #1001 as an order number)
Ok, I will change it.
The ecommerce_order_log table is a good idea. This would be useful to have exposed under the ecommerce-integration URI
Sorry I didn't understand this request) Did you mean to display the data on the page /ecommerce-integration
on our website similar I did for Order History?
Does the webhook fire for order/refund?
I will recheck it.
Can you explain why we are using a cron for creating the queued items? Is it better just to queue once a webhook is received?
I added the logic for pulling the first initial orders from a store. Let's say we have connected a store and the store has 10 orders - these 10 orders will be pulled from Shopify in this case. Later, when a webhook is triggered (let's say order/edit
), we will edit the already existing order in our system.
I can remove this logic and we can use only webhooks without initial orders pulling. Or just remove it from CRON but leave the logic itself for potential use in future. Let me know.
BTW, if yes ^, a question:
Let's imagine I've removed this initial pulling and there is an order in Shopify store. The webhook order/edit
(or any other that is not order/created
) is triggered, but we don't have the order in our system yet, shall I first create the order in our system? Or, in another case, shall I take into account only internal orders created by the webhook order/created
?
(For myself: don't forget to update the docs)
A great list. I will go through it and maybe will add something.
What shall I do with these webhooks (see the list below)? Change the status or...? If change the status, then what accordance? Or just mark them as success and do nothing?
'orders/fulfilled',
'orders/partially_fulfilled',
'orders/paid',
At the moment I just set them as successfully applied
without any changes at our site.
I can remove this logic and we can use only webhooks without initial orders pulling.
What's the reason for pulling data in advance?
BTW, if yes ^, a question
Pulling on demand seems to be enough.
Do you think it is better to just handle webhooks received from Shopify synchronously?
What's an alterantive? Shopify expects an answer syncronously. If we'll record request and process it later via queue then in Shopify it will be marked as OK regardless of actual result on our side. I'd avoid that unless processing is heavy.
What's the reason for pulling data in advance?
@samdark In fact, there is no reason. It can be a way to get N last already existing orders on the Shopify side if we don't know anything about them via webhooks. I will remove it from cron.
@cgsmith
UUID is correct on the order but the order number should match the Shopify Name (usually starts with #1001 as an order number)
Done. But I remove the #
symbol (Similar to https://github.com/CGSmith-LLC/shipwise-backend/blob/master/src/CGSMITH/Shopify.php). If you need the symbol back, let me know.
Does the webhook fire for order/refund?
Yes, it has refunds/create
. I've implemented the job for this webhook. But for the moment the job does nothing, I just mark it as success
. What shall I do with this webhook? (Also, see my other questions regarding some other webhooks I don't process above).
BYW, as I was testing the refunds, there can be two situations:
orders/updated
is sent to our site. The response has payment_status=partially_refunded
. Also, it sends the list of refunded items. It means that we can handle partially refunded orders as well. refunds/create
is sent to our side. As I wrote, it's implemented via the mock job for the moment.Pay attention. To make the webhook refunds/create
work, you need to:
It's needed to update the webhook listeners list on Shopify side for your shop.
This branch is extended from https://github.com/CGSmith-LLC/shipwise-api/pull/155
I tried to explain everything in the file ->
intro-docs/ecommerce-platfroms.md