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

...

To understand better this flow: https://www.figma.com/board/rvDVIJQKsiG1SC1yB93JVn/2024---Q4---%5BIBFEC-2795%5D---Ability-to-audit-per-store-available-and-unavailable-products-(DOP)?node-id=0-1&p=f&t=rVNPlynr4mNhYHWv-0.

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

...