# GFO planning :::info 1: Tech to support product goals ::: ## Menu Optimizations **Update to v2 menu format**: Updating the menu format to v2 gives us the ability to 1. organize our menus better in general 2. add display order to individual menu items ## Hide service fee **Update to v2 menu format**: With v1 all fees must be combined into one `DeliveryChargeSPecification`. With v2 there are two types of fees: `SERVICE` and `DELIVERY`, which is possibly what the other providers are utilizing to get past the service fee showing up at top of funnel. ## Curbside I have a question out to the Google team about feed JSON requirements (if we need v2 or not). Otherwise, I think this is just a matter of reading a restaurant setting and adding it to the feed entity. ## Order ahead I'm not sure why this isn't already working. I see `advanceBookingRequirement` specifications in the gfeed code as well as in a couple of the entity files I checked. ## Promos We currently use `Deal` to set the shop discount. Deals also have an `eligibleMaxOrders` property which we could set to 0 for new customers. More about the deal properties [here](https://developers.google.com/actions/food-ordering/reference/relational-inventory-schema?authuser=0&hl=en#deal). ## Marketing opt in Looks like we already pick this up when we process the transaction request ([docs](https://developers.google.com/actions/food-ordering/guides/additional-features/remarketing-opt-in?hl=en&authuser=0)). Might be a matter of updating admin to change the user's data. ## Menu too big There's a possibility that we could divide these menus into more files and get past this. Another possibility is that v2 format is smaller and will alleviate this issue. --- :::info 2: Tech debt, known problems, and refactroring needs ::: ## Update Ruby and Rails. Fix security issues in dependencies. Both repos use version of Ruby (and hence Rails) that are too old. That needs to be tackled asap. We also have a ton of dependabot warnings. A lot of these can be resolved by updating the Ruby/Rails versions which will facilitate also updating these dependencies. Quite a few of these dependencies couls be removed all toghether since many are not used any more. During this process we should also make sure our unit tests are **solid** so we can avoid using scientist for future development. ## Remove all old scientist candidate code There is still old scientist code in the gfood repo that should be removed asap to help with readability and maintenance. ## Menu feed generation We need to move away from the update-all-shops-at-night approach and transition to an event based feed generation. With that refacor we might also consider switching to v2 JSON format for the entirety of our feed (some parts already are). **Benefits:** 1. Decrease the number of ordering errors due to out of sync menu data. 2. Decrease error due to out of sync service hours. ## Create valid error responses for all pricing errors Last month our pricing success rate was only 80% and out of the errors 66% was invalid JSON caused by empty error messages being sent back. Seems like a problem we should solve. Analytics live [here](https://console.actions.google.com/u/0/project/vertical-dryad-164314/analytics/fopatransactions). :::warning **Priorities:** 1. Update code base to latest version of Ruby etc. 2. Fix security vulnerabilities. 3. Move Gfeed to event based architecture. 4. Curbside integration (granted Google is ready). :::