The following details quoted are from: https://rbictg.atlassian.net/browse/TRX-397. To have the more updated details check on the Jira.

Context

In Portugal and Spain, many restaurants have a break in their delivery schedule during the day (for example delivery available from 12.00-16.00 and 18.30-23.30). In a previous task we worked to account for that by repurposing the dinner time open and dinner time close fields in Sanity. Now the logic is:
A. Store only has delivery time open and delivery time close fields set = continuous delivery service within these times
B. Store has delivery time open, delivery time close and dinner time open, dinner time close set = restaurant has two separate delivery blocks with dinner time open, dinner time close being the later one
We now need to display these information to the guest in the FE. We currently only display the delivery time open and delivery time close timestamps in the FE under restaurant information

Acceptance Criteria - Whitelabel

- The new delivery times and different blocks need to be displayed in the FE of our platform for the guest to know and see when delivery is available.
- Ability to Configure by brand & market if we should display the field dinner time open and dinner time close as additional slots in the FE to the guest. Field example (also see the SQL file screenshot below):
- dinnerFriOpen
- dinnerFriClose
- MDM fields are Dinner time open, dinner time close and being used in Sanity as additional time slot under delivery hours (see image below):
- If a store has only delivery time open, delivery time close set, we can display the information as they are right now
- If a store has delivery time open, delivery time close, dinner time open, dinner time close set in the system, we need to display both slots to the guest in the FE
- Designs: Guest App
- The fulfillment service that determines whether delivery is available should take the additional delivery slot hours into consideration while evaluating hours of operation.
- See this conversation for more details: https://rbidigital.slack.com/archives/C05HM8CUBL4/p1691058316671209?thread_ts=1690986623.895639&cid=C05HM8CUBL4

The Sanity solution is already implemented on the following ticket: https://rbictg.atlassian.net/browse/TRX-309

New fieldset “Additional Time Slot” available for delivery hours sync

The US for Iberia Dedicated Team:

Frontend analysis and tasks breakdown

Figma:

Store info modal design. Take away represents the “default” and “Delivery Hours” is showing the new info

Reinforcing the Acceptance Criteria

If a store has only delivery time open AND delivery time close set (the default infos, without the additional time slot)
- Display the information as they are right now (in the image above the “Take Away” info)
If a store has delivery time open AND delivery time close AND dinner time open AND dinner time close (in the end, this means that we’ll need all four infos)
- Display both slots (breaking time) to the guest in the FE (the “Delivery Hours” section in the image above)
We’ll always show the information with high priority on the Store Locator page. As the Figma example the “Take Away/Dine in Hours” will decide what will be shown: ← Validate this with Simon/Intl
- A: We should not touch the highlight information that we have outside as this will always look to the Take Away/Dine in Hours (that don’t have additional slot information)
We’ll keep the logic made for restaurants that closes after midnight ← Validate this with Simon/Intl
- A: Yes
Do we’ll need to consider other open/close rules? ← Validate this with Simon/Intl
- A: The main point is to understand what we’ll have on Sanity. Noting else was mentioned. Logic and Sanity explanation will be below.
For the feature to work correctly, we need to maintain a correct configuration for each field if not will be difficult to add extra logic to handle “multiple cases”: ← Validate this with Client/intl
- Bad data (Monday example):
  - Open: 22
  - Breaking time close: 02 (Tuesday hour)
  - Breaking time opens: 05 (Tuesday hour)
  - Closes: 11 (Tuesday hour)
- Correct data:
  - Open: 05 (Monday hour)
  - Breaking time close: 11 (Monday hour)
  - Breaking time opens: 22 (Monday hour)
  - Closes: 02 (Tuesday hour)
- The two data are the same and the difference is that the second one (correct data) is a logical approach that facilitates the logic on the FE side.

Output of the analysis of the code and tasks breakdown

Did research in the code and discovered that we had an implementation regarding this on this PR: but reverted here. By the revert description, the cause was “We need to revert this because of a mistake in the requirements.” We have the option to bring the reverted PR back or work again on the same adjust ← Understand what was this mistake Simon/Intl

A: We had a meeting with Simon and he explained all the details regarding this implementation. For more details meeting recording: Separate delivery blocks - discovery-20231010_120348-Gravação de Reunião.mp4 (rbi account needed to open)

The following solutions and tasks are based on the solution proposed by @Odang, Kristoforus. Kudos to him.

Note: For the Store Locator page we think that will be not necessary to show the information regarding the breaking time hours as this only will work for Delivery Hours. The highlight information will be about the “Take Away/Dine in Hours” meaning that we’ll not need to pass down this info through the components.

Sanity

Task 1 - Fix the wrong texts on Sanity

The actual fields are wrong in Sanity. “Opens again at” is equal to breaking time start (restaurant closes) and “Closes” is equal to breaking time ends (restaurant opens).

New proposal:

Figma:

New labels:

Additional Time Slot Description → Operation break (Restaurant Closed)
Additional Time Slot Description → MDM Sync. Time when the restaurant has a break in its operation, but reopens on the same day
Opens again at → The break starts at
Closes → The break ends at

Whitelabel App

Task 1 - Generate missing Sanity Graphql and add additional info on `mergeRestaurantData`

Create a new feature flag on LaunchDarkly and add to the code: highlight-breaking-time-slot

In the reverted PR, some of the types from the generated command were kept but we’ll need to have that again so will be good if we run the yarn apollo:generate again to see if we'll have any change and to add again what's missing.

Add new additional information to the RestaurantFragment

fragment RestaurantFragment on Restaurant {
  _id
  environment
  chaseMerchantId
  deliveryHours {
    ...HoursFragment
    sunAdditionalTimeSlot {
      close
      open
    }
    monAdditionalTimeSlot {
      close
      open
    }
    tueAdditionalTimeSlot {
      close
      open
    }
    wedAdditionalTimeSlot {
      close
      open
    }
    thrAdditionalTimeSlot {
      close
      open
    }
    friAdditionalTimeSlot {
      close
      open
    }
    satAdditionalTimeSlot {
      close
      open
    }
... // rest of the file

Add a new type additionalHours on some files

Create a new file on src/utils/restaurant/types.ts:

export enum HourOfOperationType {
  CURBSIDE = 'curbsideHours',
  DELIVERY = 'deliveryHours',
  DINING_ROOM = 'diningRoomHours',
  DRIVE_THRU = 'driveThruHours',
}

src/types/store.d.ts:

export interface IStore {
  // ... rest of the file
  additionalHours: Record<HourOfOperationType, IStoreHoursOfOperation>;
  // ... rest of the file
};

src/state/store/hooks/utils.ts:

src/fixtures/order.ts:

src/fixtures/store.ts:

Add the new informations on mergeRestaurantData function

This method will be responsible for letting us get the needed data to be shown on the FE side. We can format/adjust the data from Sanity to what we want/need for the rest of the solution.

In Odang’s code, he create a placeholder to help standardize the information for the other hours information. Feel free to analyze this

DOD Like

Test using a console to see if the new data you be shown

Task 2 - Extend Hours comp to receive the new additional information

Now that we can get with success the data from Sanity (implemented on task 1) we need to pass this down to the three components.

Pass the info to <Hours> comp (use inside StoreInfoModalcomp)

Add the new param to <Hours> comp and get the additional info for the current day

DOD Like

Test using a console to see if the new data you be shown
If needed remember to use our feature flag highlight-breaking-time-slot

Task 3 - Show the new additional hour information on the interface

Add the new infos on the <Hours> comp used inside src/components/store-info-modal/index.tsx. I’ll let this be free for those who implement this. You can also take a look at Odang’s code

DOD Like

The layout should be as described in Figma
If needed remember to use our feature flag highlight-breaking-time-slot

Task 4 - Highlight: Pass the new information through our `<StoreStatus>` comp and add new logic on the `useStoreStatus` hook

Now our highlight feature needs to be adjusted to deal with this new hours information.

Obs: after Task 1 the labels and texts will be fixed and the image below will not be precise. Feel free to update here after task 1 is done

To be more didactic I’ll considere the following for the rest of this task:

Time	Sanity label (Delivery hours)	Meaning to the business

Time	Sanity label (Delivery hours)	Meaning to the business
09:00:00	Monday Time Open	general opening hour
12:00:00	Additional Time Slot - Opens agains at	breaking time closing hour
15:00:00	Additional Time Slot - Closes	breaking time opening hour
22:00:00	Monday Time Close	general closing hour

New logical rules

We’ll have new validations if we receive breaking time opening hour AND breaking time closing hour (meaning that we’ll have the four hours). This is a way to deal with it. If we don’t have this information we’ll keep the logic that we have implemented today
- Open’s at (1 hour to open rule):
  - Time now <= general opening hour OR (Time now >= breaking time closing hour && Time now <= breaking time opening hour)
- Closed now:
  - Time now >= breaking time closing hour AND Time now >= general closing hour
  - Time now <= general opening hour (out of the 1 hour to open rule)
  - Time now >= breaking time closing hour AND Time now <= breaking time opening hour (out of the 1 hour to open rule)
- Open now:
  - Time now >= general opening hour AND Time now <= breaking time closing hour OR Time now >= breaking time opening hour AND Time now <= general closing hour (out of the 1 hour close rule)
- Close’s at (1 hour to close rule):
  - Time now >= general opening hour AND Time now <= breaking time closing hour OR Time now >= breaking time opening hour AND Time now <= general closing hour (inside 1 hour close rule)
- Add a preventive validation:
  - If we don’t have all four hours: the default logic should be used
  - If we have all four hours but the breaking time closing hour > general opening hour: the default logic should be used
  - If the feature flag highlight-breaking-time-slot is OFF the default logic should be used

Option 1 - Keep the code that we have there and add new logic

Just add the new rules above inside the getStoreStatusmethod

Option 2 - Break down the `getStoreStatus` method into other methods

This method already has a high cognitive complexity:

The ideal would be:

The creation of new methods to isolate each of these necessary logics
- Default hour rule for restaurants (only open/close hours)
- Restaurants that close after midnight rule
- Breaking time rules

As a suggestion we can always look through the input that we’re receiving. This will guide which method/logic we’ll need to call. We can also define/discuss this in an A&D section.

DOD Like

Adjust the unit tests for the new implementation/refactor
Manually test if all is good with:
- Regular logic rules
- Restaurants that close after midnight rules
- Breaking time rules
If needed remember to use our feature flag highlight-breaking-time-slot

Iberia Collaboration

Additional delivery Breaking Time hours

Frontend analysis and tasks breakdown

Output of the analysis of the code and tasks breakdown

Sanity

Task 1 - Fix the wrong texts on Sanity

Whitelabel App

Task 1 - Generate missing Sanity Graphql and add additional info on `mergeRestaurantData`

Task 2 - Extend Hours comp to receive the new additional information

Task 3 - Show the new additional hour information on the interface

Task 4 - Highlight: Pass the new information through our `<StoreStatus>` comp and add new logic on the `useStoreStatus` hook

New logical rules

Option 1 - Keep the code that we have there and add new logic

Option 2 - Break down the `getStoreStatus` method into other methods

Frontend analysis and tasks breakdown

Output of the analysis of the code and tasks breakdown

Sanity

Task 1 - Fix the wrong texts on Sanity

Whitelabel App

Task 1 - Generate missing Sanity Graphql and add additional info on mergeRestaurantData

Task 2 - Extend Hours comp to receive the new additional information

Task 3 - Show the new additional hour information on the interface

Task 4 - Highlight: Pass the new information through our <StoreStatus> comp and add new logic on the useStoreStatus hook

New logical rules

Option 1 - Keep the code that we have there and add new logic

Option 2 - Break down the getStoreStatus method into other methods

Task 1 - Generate missing Sanity Graphql and add additional info on `mergeRestaurantData`

Task 4 - Highlight: Pass the new information through our `<StoreStatus>` comp and add new logic on the `useStoreStatus` hook

Option 2 - Break down the `getStoreStatus` method into other methods