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.

🧐 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.

...

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:

Image RemovedImage Added

• 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)

...

• 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:

1. To-doInfinite Scroll

2. To-do

✅ Proposed Solution

New page to audit products

Important: TheUX 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)

...

export interface AuditProductsState {
  auditableProducts: Record<string, desiredFragmentHere>;
}

/**
 * Audit products redux store
 */
export const auditProducts = createModel<RootModel>()({
  state: {
    auditableProducts: false,
    filters: {
      // any desirable filter, if we want
    },
  } as AuditProductsState,

  reducers: {
    /**
     * Method to set the auditableProducts
     */
    setAuditableProducts(state, payload: desiredProductsInterface) {
      return { ...state, auditableProducts: payload };
    },

    // any other filter reducer if necessary
  },

  selectors: slice => ({
    auditableProducts() {
      return slice(state => state.auditableProducts);
    },
  }),
});

import { Models } from '@rematch/core';

// ...rest of the code
import { auditProducts } from './audit-products';

export interface RootModel extends Models<RootModel> {
  // ...rest of the code
  auditRestaurants: typeof auditProducts;
}

export const models: RootModel = {
  // ...rest of the code
  auditProducts,
};

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

🧑‍🚒 QA Plan

⚠️ Call-outs

...