Closed mattsahn closed 1 year ago
@mattsahn I made a branch that pulls the text messages by recursively searching the json for the twilio module schema and having the body start with (Grassroots Grocery)
. In testing this worked for all the texts. Performance wise it seems to be fine also.
I can open the PR also if you would like.
I have it on this branch here: https://github.com/grassrootsgrocery/admin-portal/blob/f593db15097acd9ab69f5cc9844409ea68addcaf/server/routes/messaging.ts#L70-L92
That's pretty cool searching the whole blueprint, @6mp. Very clever approach. But, I think the notes approach will actually end up working better for the user experience, since the raw text message has all the variables in it so isn't very readable currently. Example:
With the note approach, we can make a more intuitive looking sample text for the user:
(Grassroots Grocery) Hi, [COORDINATOR] ! There is 1 driver with 2 total loads scheduled for [DROPOFF SITE]. Driver 1: Name: [DRIVER] Total loads of food: TWO loads of food Estimated Departure Time: [TIME] Phone #: (xxx) xxx-xxxx
It's also probably possible for some scenarios to have multiple twilio modules in it that would be arbitrary for what it pulls. The note will require some maintenance in Make, though, but I think it's manageable.
@mattsahn Sounds good, I implemented it the other way but I think a couple of the scenarios are archived. I'll talk about this in the PR further.
This enhancement is to change the way we fetch sample text message to display in the frontend where the user can trigger a message to be sent. Currently, the implementation is fragile in that it depends on fetching from a specific part of the Make scenario blueprint, which we fetch from Make like this:
https://github.com/grassrootsgrocery/admin-portal/blob/215094cd8d6bd2d204c85cf7ee2260813bbe190e/server/routes/messaging.ts#L81-L96
and this:
https://github.com/grassrootsgrocery/admin-portal/blob/215094cd8d6bd2d204c85cf7ee2260813bbe190e/server/routes/messaging.ts#L182C2-L206C3
The part that is fragile which we need to change is the final line that pulls where the text message was:
data.response.blueprint.flow[3].routes[0].flow[1].routes[1].flow[0].mapper.body
These can break anytime the scenario changes, which is why we need a permanent solution that will be resilient over time and allow us to still modify the sample text message without needing to hard-code.
To address this, we can instead save the same text message as a make "note". In Make, notes can be added anywhere like this:
The notes always show up in the scenario json in the same place, response.blueprint.metadata.designer.notes, but there can be multiple notes so the order or id number aren't known. So, the code must iterate/search all the notes' text and choose the one that begins with "(Grassroots Grocery)" as a convention, then return that one as the text to display in the app:
If there are no notes or no note is found matching that text, this should be handled by falling back to use response.blueprint.name which is just the actual scenario name:
See issue #118 for additional background...