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

"Amount" on Delivery Report does not account for order edits #8019

Closed
filipefurtad0 opened this issue Aug 9, 2021 · 3 comments · Fixed by #8160
Closed

"Amount" on Delivery Report does not account for order edits #8019

filipefurtad0 opened this issue Aug 9, 2021 · 3 comments · Fixed by #8160
Assignees
Labels
bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround.

Comments

@filipefurtad0
Copy link
Contributor

Description

After an order is placed, the Amount displayed in the Delivery Report does not reflect subsequent order edits (ex. by adding or removing items)

Expected Behavior

The "Amount" column on the Delivery Report should reflect changes on the order total, from editing an order.

Actual Behaviour

The "Amount" column on the Delivery Report does not reflect changes on the order total: it displays the initial order total.

Steps to Reproduce

  1. Place an order.
  2. Visit /admin/reports/order_cycle_managementand find the line corresponding to the customer and order
  3. Edit the placed order, ex. remove some line items; issue a refund (pic below).
  4. Compare the order total found on /admin/orders/<order_nr>/editwith the Amount one found on the Delivery report: the latter still displays the initial order total (before the order edit).

Animated Gif/Screenshot

image

Workaround

None;
Proposing S3 as I'm not really sure on the impact on this one.

Severity

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

Your Environment

  • Version used: v3.8.8
  • Browser name and version: Firefox 90
  • Operating System and version (desktop or mobile): Ubuntu 20.04

Possible Fix

@filipefurtad0 filipefurtad0 added the bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. label Aug 9, 2021
@lin-d-hop
Copy link
Contributor

I actually think this should be an S2.

A workaround of 'look at a different report for the same information' shouldn't be a workaroud. How is a user supposed to know which report is correct?

This has caused a bit of confusion in the UK that I was struggling to track down... only just spotted this issue. Nice catch @filipefurtad0

@lin-d-hop lin-d-hop added bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround. and removed bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. labels Sep 4, 2021
@lin-d-hop
Copy link
Contributor

@apricot12 This might be one you can look at? Getting your head into reports would be really great at the start of the reports project :-)

@apricot12
Copy link
Contributor

@apricot12 This might be one you can look at? Getting your head into reports would be really great at the start of the reports project :-)

Since this is an S2, I'll prioritize this and start on Monday 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants