Acceptance Criteria

1. Access to the Audit Page

Given the operator is on the restaurant selection page on the DOP platform,
When they select one or multiple restaurants and click the “Review Restaurants” button,
Then they should be redirected to the audit page displaying product availability data.

2. Product Availability Filtering & Searching

Given the operator is on the audit page,
When they enter a product name in the search bar or apply filters,
Then the displayed table should update to show only the matching products.

3. Infinite Scroll for Product List

Given the operator is viewing the product table,
When they scroll down,
Then more product data should load dynamically without pagination buttons.

4. Product Audit Report Download

Given the operator has applied filters on the audit page,
When they click the “Download Restaurants Report” button,
Then a report should be generated and downloaded containing only the filtered data.

5. Automated Product Reactivation Reminder

Given a product has been disabled,
When it reaches a predefined reactivation threshold,
Then an automated reminder should be sent to the Store Manager.

6. Real-Time Product Availability Updates

Given a product’s availability status changes,
When the operator accesses the audit page,
Then the updated status should be reflected in real-time.

7. Efficient Backend Data Handling

Given a user requests product data via the audit page,
When the system retrieves data from the backend,
Then it should use AWS Elasticache to ensure fast response times.

8. Error Handling for Data Retrieval

Given the system fails to fetch product availability data,
When a query to DynamoDB or Elasticache fails,
Then the user should see an error message and a retry option.

9. Monitoring & Logging

Given the system is live,
When users interact with the audit page,
Then logs should be recorded in Datadog for monitoring usage and errors.

https://rbictg.atlassian.net/browse/IBFEC-2795

Context

The current DOP platform currently lacks a way to manage disabled products across its global Markets, leading to prolonged periods of product unavailability and sales losses.

Store Managers disable products for various operational reasons (stock shortages, equipment maintenance, etc.), but these products often remain disabled because there is no automated reminder or reactivation process in place. This issue was previously managed by the Iberia Operations Team, who would proactively check for disabled products.

With the current migration to the Whitelabel Platform, this manual process is not reliable anymore and products remain disabled for longer periods than necessary, impacting both user experience and business performance. Customers experience frustration when their desired products are consistently unavailable, leading to decreased retention rates and lost revenue opportunities.

To address this, we propose an enhancement to the DOP system, allowing for better auditing and management of product availability.

Potential Solutions

For the navigation/flow experience, this will be the summarized solution:

The audit process starts when the user clicks on the "Review Restaurants" button in the /restaurants page
The user will be sent to a new route /audit-products
On this new page, we'll show the new products table for the audit restaurants experience
The user can also download products status (the filtered products to a CSV file)

About DOP Performance

Today we already know that the application has performance problems to deal with big content on the table (high loadings, slowness, etc.). To deal with this problem, we have the following proposals:

Infinite Scroll
To-do

Proposed Solution

New page to audit products

Important: The UX team is defining the experience. This document is already out-dated. The main idea could be reused still.

# 1 - Create new page, route and state management property

Create a new route /audit-products (suggestion)

// ...rest of the file

const AuditRestaurantProducts = lazy(() => import('./pages/audit-restaurants-products'));

const App: React.FC = () => {
  // ...rest of the function

  return (
    <BaseLayout>
      <Suspense fallback={null}>
        <Routes>
          // ...other routes
          <Route
            path="/audit-products" element={<AuditRestaurantProducts />} />
        </Routes>
      </Suspense>
    </BaseLayout>
  );
}

Create a new component to represent the new audit page (suggestion: AuditRestaurantProducts)
- We need to include the common structure for pages following the current pattern
- Create a new component to show the header with the new button “Download products status”
  - We’ll need to get here any state related data to download the products status
  - We’ll use the PageHeader as main container inside this new component (ex: PaymentMethodsHeader)
- Create a new component to show the footer (suggestion: AuditProductsFooter)
  - On this footer, we’ll only have the cancel button that will send the user back to the /restaurants page
- Adjust the EditorBar component to show the new “Review Restaurants” button
  - This button will be shown if we’re on the /restaurants page, and select at least one restaurant (restaurant tab) OR one group (groups tab)

// ... Rest of the code above. Component return example
return (
    <Page>
      <PageHeader>
          // Editor title example
          <EditorPageTitle>{formatMessage({ id: 'audit-products.header' })}</EditorPageTitle>
          // Desired content here
      </PageHeader>
      <PageContent hasActionBar>
        // Desired content here
      </PageContent>            

      // New footer component
      <AuditProductsFooter />
    </Page>
);

Interface example:

PS: The prints below are already outdated, but the idea and logic will be the same. The button label will be “Review restaurant”

Code adjustment example:

export const EditorBar: React.VFC<EditorBarProps> = memo(function EditorBar({ type }) {
  // ...rest of the code
  
  // New lines
  const selectedGroups = useRematch(select.restaurantGroups.selectedGroups);
  
  // We need to check the type restaurants because this Editor bar is used in other pages
  // as well (products page, for example) and as this state is global (Rematch) we don't want
  // to show this button there
  const selectedGroups = useRematch(select.restaurantGroups.selectedGroups);
  const hasGroupSelected = type === 'restaurants' && !!selectedGroups.length;
  const hasRestaurantSelected = type === 'restaurants' && !!selectedRestaurants.length;
  const isReviewRestaurantEnabled = hasGroupSelected ?? hasRestaurantSelected;

  // ...rest of the code
  
  // new function to navigate the user
  const handleAuditRestaurants = useCallback(() => {
    navigate('/audit-products');
  }, []);
  
  return (
    <ActionBar active={isModalVisible ? false : isEditing}>
      <ActionBarInner>
        // ...rest of the code
        <ActionBarEnd>
          {!isCopyMode && (
            <>
              // ...rest of the code
              )}
              {isDropdownEditor ? (
                // ...rest of the code
              ) : (
                // ...rest of the code
              )}
              // New audit button
              {isReviewRestaurantEnabled && (
                <Button large onClick={handleAuditRestaurants}>
                  Review Restaurants
                </Button>
              )}
            </>
          )}
         // ...rest of the code
        </ActionBarEnd>
      </ActionBarInner>
    </ActionBar>
  );
});

Create a new component for the audit products table
- This new component can be based on the current frontend/src/pages/products/products-content/ProductsContent.tsx implementation
- Our new table will be similar to this one, but
  - We want a better experience, not a copy/paste
  - We’ll have new columns (besides the current ones in the products table)
    - Name
    - Availability
    - Updated
    - Price
    - Service Mode
    - Channel
    - Type
    - Section
    - PLU
    - Internal Name
    - Restaurant
    - ID
- To filter the table we’ll need the following filters
  - Search products text field
  - Availability
  - Service mode
  - Channel
  - Type
  - Section
  - Restaurant
Create a new store property to manage the related state
- Motivation: isolate and separate responsibilities. Let’s the current products state untouched (the menu store).
- The new “Download products Status” button lives in the application header. We’ll need to save in memory the products filtered result to be able to generate the CSV when clicking in the header button

Update the Rematch models index:

Front end to-do: Do we need a pagination system? The solutions to deal with performance problems and querie section will answer that.

Note: If yes, as a suggestion, we can consider using the Material UI pagination component because it is very flexible and we can customize the visuals if we want (the app appears to lack a pagination component for the tables). This library is already in use in other applications, like admin-app, so it’s approved for use.

New logic to schedule and automatic reactivation of disabled products

To-do: to confirm if this will be part of this first deliverable or if we’ll only deliver the audit page for now.

Solutions to deal with performance problems and queries

Today the app depends on data from different places to have the products complete data (considering availability, etc). I'll let here just an example of how the data flow is working for the products page/editor flow → This is only intended for the discovery/draft phase. We can delete this text and the image below later.

To-do: proposals to solve this data composition/orchestration layer for the new page and products data

# 1 - To-do solution 1

Metrics

Describe the metrics that will be used to measure the solution’s success, as well as how to measure those KPIs.

QA Plan

Testing scenarios. See example here.

Call-outs

Tip: Document here any improvement or discussion regarding the feature

Iberia Collaboration

--- to be deleted --

Analytics