Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-empty orders in the cart state do not appear in orders page #11120

Closed
filipefurtad0 opened this issue Jun 26, 2023 · 2 comments · Fixed by #11348
Closed

Non-empty orders in the cart state do not appear in orders page #11120

filipefurtad0 opened this issue Jun 26, 2023 · 2 comments · Fixed by #11348
Assignees
Labels
bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. regression Tagging any identified regressions

Comments

@filipefurtad0
Copy link
Contributor

filipefurtad0 commented Jun 26, 2023

Description

PR #8148 introduced hiding of cart orders, with no line-items.

It seems that since more recently, even non-empty orders are not appearing on the /orders page.

Expected Behavior

Non-empty orders in the cart state, should appear in the /orders page.

Actual Behaviour

Non-empty orders in the cart state, are not appearing in the /orders page.

Steps to Reproduce

As a customer:

  1. Visit a shop and add some items to the cart; proceed to the /details step.

As a hub:
2. Visit the /orders page
3. Uncheck "Display only complete orders"
4. Filter results -> notice the order is not appearing in the results

Animated Gif/Screenshot

Workaround

None; cart orders cannot be edited by the hub.

Severity

bug-s2: a non-critical feature is broken, no workaround

Your Environment

  • Version used: v4.4
  • Browser name and version: Firefox 113
  • Operating System and version (desktop or mobile): Ubuntu 22.04

Possible Fix

From the spec #11121, it looks like non-empty cart orders:

  • with non-null bill_address_id and ship_address_id -> appear on the /orders page
  • with null bill_address_id and ship_address_id -> do not appear on the /orders page

This may relate to split-checkout design, in which orders only get address info after submitting the data from the /details step... However, moving from /details -> /payment changes the order state from cart -> payment...

@filipefurtad0 filipefurtad0 added bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround. regression Tagging any identified regressions labels Jun 26, 2023
filipefurtad0 added a commit to filipefurtad0/openfoodnetwork that referenced this issue Jun 26, 2023
@lin-d-hop
Copy link
Contributor

I'm not sure this is an s2. I don't think viewing uncompleted carts counts as 'critical feature'.

Downgrading to s3 until a user complains.

@lin-d-hop lin-d-hop added bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. and removed bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround. labels Jun 26, 2023
filipefurtad0 added a commit to filipefurtad0/openfoodnetwork that referenced this issue Jul 3, 2023
@github-project-automation github-project-automation bot moved this to All the things in OFN Delivery board Aug 7, 2023
@RachL RachL moved this from All the things to Dev ready 👋 in OFN Delivery board Aug 7, 2023
@abdellani abdellani self-assigned this Aug 7, 2023
@abdellani
Copy link
Member

Hi @filipefurtad0

Case 1: As a user (or a guest) who has already set a billing address

It is not possible to reproduce this bug with a registered user (or a guest) who already set his billing address
When I visit a shop, an order is created in the background. That order will start with state=address and will not be visible on the admin dashboard.
As soon as I add a new line item, the order becomes visible.
image

Case 2: As a user (or a guest) who didn't set a billing address

When the user accesses a shop and adds some line items, the order will start with state=cart and will stay invisible until the user submits the first form on the split checkout.
This is happening because, on the first step the billing address will be set.

One potential solution is to ignore the billing address, I'll draft a PR and see what will be the impact on the tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. regression Tagging any identified regressions
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants