Send Review invites based on order Status - ReWork

[DomiKoch]

Description

Hi @Mhera17 ,

as mentioned in our meeting, we want to improve the connector layer to be able to "send review invites based on order status". These implies following changes:

• enable user to define any order status + checkout event as trigger to send review invites
• they can choose different statuses to trigger Service Review Invites and Product Review Invites
• They no longer need to explicitely activate the collection of product reviews

The detailed briefing is on:
MiroBoard
Designs:
In Figma

Please use this issue for further questions.

Timing:

First Version: August 14th
Focused Testing - Improvements in close cooperation: August 14th - August 23rd
Final Version: August 23rd

If we are able to test earlier, of course we will begin as soon as you can deliver us.
I will prepare the content keys in this week and send you a draft.

Greetings

References

[DomiKoch]

Hi @Mhera17 ,

do you have any status updates? Do you have questions?

@saidtahali this is the ticket for our new feature "send review invites based on order status"

Greetings

[Mhera17]

hi @DomiKoch ,
I have finished the UI part.
now I'm working on the functional part.
I will post questions later.

[DomiKoch]

Hi @Mhera17 ,

Could all questions be clarified? How is the progress going?

Greetings

[Mhera17]

Hi @DomiKoch. good. Now I'm implementing the functionality of the Save button. Many of the answers to my questions I have found on the Miro board. Now I just need content keys and links for "upgrade now" and "control center". Can you please send it?
And about "The list of statuses must be provided by base layer." - I just want to clarify. Do I need to create a new function in the baseLayers folder(img) that returns a list of statuses({key: 'checkout', ID: 'checkout'})?

[eburck]

Hi @Mhera17 , may I just jump in.

Yes, please create new function (event) that sends list of available statuses with test data.
Sensible data could be (example from Presatshop):
[
{name: 'Awaiting Payment', ID: 1 },
{name: 'Payment accepted', ID: 2 },
{name: 'Processing in progress', ID: 3 },
{name: 'Shipped', ID: 4 },
{name: 'Delivered', ID: 5 },
{name: 'Canceled', ID: 6 },
{name: 'Refunded', ID: 7 }
]
As 'checkout' is not a status by the shop but set from our side, this will not be stated in this list.

In return, connector needs to provide the selected status to base layer.
This can be either 'checkout':
{name: 'checkout', ID: 'checkout' }

or any of the ones provided via list, e.g:
{name: 'Shipped', ID: 4 }

It might be helpful to provide name of event_type, as well. What do you think about it?:
for 'checkout':
{name: 'checkout', ID: 'checkout', event_type: 'checkout' }

or for any of the ones provided via list (example for Prestashop):
{name: 'Shipped', ID: 4, event_type: 'order_status_from_Prestashop' }
event_type must have the same value as the one that has been created inside connector layer (POST /event-types)

[Mhera17]

Hi @eburck.
I guess this one will be better, isn't it?
{name: 'checkout', ID: 'checkout', event_type: 'checkout' }

[DomiKoch]

Hi @Mhera17 ,

i added the keys in the miro board.

Greetings

[DomiKoch]

HI @Mhera17 ,

hope you are doing well... Everything in the green zone for a first version on monday?

Greetings
Dominik

[Mhera17]

Hi @DomiKoch,

I'm not sure I can finish the first version before Monday.
I'll try to finish tomorrow, but I think it might take a few more days.

[Mhera17]

Hi @eburck , @DomiKoch

For now, I've added a GET_AVAILABLE_ORDER_STATUSES event to the library and base layer to provide a list of statuses.
While I'm not clear on a couple of things.

1. When loading the connector, we must, as in the previous version, request GET /invite-settings and GET /event-types and receive the GET_USE_ESTIMATED_DELIVERY_DATE_FOR_CHANNEL and GET_USE_EVENTS_BY_ORDER_STATUS_FOR_CHANNEL events for the selected channel?
   If I understand correctly, we need to add a few more events to the library that will save the selected value from the list for serviceInviteConfiguration and productInviteConfiguration on the side of the base layer? and then provide those selected values so we can match them and display them in the connector?
   Or how do you think they should be matched?
2. Do I understand correctly that ELSE is the selected value, except for the checkout exception, and OTHER is not selected?
3. Reset for marked with a cross should be done before all sendings?

[eburck]

Hi @Mhera17 ,
Thanks for your work so far.
ad 1) Yes, that's correct. Please add appropriate events to connect-app-eventslib.
ad 2) As you said, ELSE stands for a selected order status besides 'checkout'. OTHER symbolised that for product and service reviews different order statuses has been selected besides 'chekcout'.
ad 3) I will leave that up to you. What do you think is better in regards of reliability?

[Mhera17]

thanks, Eberhard.
ok, I will think in the process and let you know.

[Mhera17]

Hi @eburck , @DomiKoch

1. (image) In this step, we create a new event type post /event-types.
   after creation, we must patch /invite-settings for the created event-type, but the problem is that a new event-types in /event-types is created immediately, but the object associated with it in /invite-settings is created in the database automatically and with a delay and when I try to patch /invite-settings we get an error that there is no such id in the settings corresponding to the created event-type.
   Am I doing everything right and understanding right at this stage?

2. do we take the selected value when loading into the product/service selectors from what the baselayer gives? Or is it somehow necessary to match with those who have enable:true from the API?

[Mhera17]

3. what is meant here, after saving new data in API and baselayer

[eburck]

Hello @Mhera17 ,

ad 1)
From my side you understand correctly. With the eventType ID in return of calling POST event-type you should be able to do the PATCH invite-settings?event-type-id=xxx.
This has been already implemented for the old order_shipped status, as well. How was that done to overcome the issue of delay you mentioned?

ad 2) we just take the selected value and list from what the baselayer gives.

ad 3) That was only a rough draft about what data needs to be handed back to baselayer for storage. With handing back something like {name: 'Shipped', ID: 4, event_type: 'order_status_from_Shopsystem' } for each review type (service / product), nothing else needs to be done.

[Mhera17]

Thanks @eburck , @DomiKoch

I deleted order_shipped via Postman for my account and created it again in the old version and got the error too.
Is it possible to try it on other accounts? I take it there was no error before?

[eburck]

Hm, that's not good. I can reproduce it also for other accounts. That is a new thing.

[Mhera17]

hi @eburck @DomiKoch.

did anything change in the API?
And is it possible to make it so that the response to the post /event-type comes after the object associated with the new type is created on the backend in the invite-setting list?

[eburck]

Hello @Mhera17, I am still in exchange with our developers.

[Mhera17]

Hello @eburck @DomiKoch, Thanks, I'll be waiting for updates. and focus on this ticket.
#47

[Mhera17]

hello @eburck , @DomiKoch .
I have finished the functionality and UI. (still need translations to finish this ticket).
I changed the index.html file to have access to eventsLib from the public folder. I will revert it after you test.
#52

[DomiKoch]

Hi @Mhera17 ,

do you mean the translations of the keys? I will put them in phrase when they are ready.

Greetings

[Mhera17]

thanks a lot @DomiKoch