1.4 -- Sales Order regression -- cannot update existing sales order

[freelock]

Hi,

We hit (again) the workflow issues creating sales orders and partially shipping them on invoices that have been a problem for a couple of months.

I just set out to create an issue for this based on the tip of 1.4 -- and found that it mostly works! Thanks for getting that squared away.

I'm still seeing one issue though:

1. Create a sales order, add some line items, and save.
2. Search for the sales order using Order Entry -> Reports -> Sales Orders, and re-open
3. Change the contents of the order -- e.g. the qty of the first line item, and update.
4. Click save.

Result: the line item disappears, and the invoice is now $0.

It gets a bit worse:

1. Add a line item back as the first entry.

Error!
'LedgerSMB::PGNumber Invalid Number at LedgerSMB/PGNumber.pm line 167.

... If you click the back button, and update, you can apparently add a line item successfully -- but if you save and then re-open the sales order, same result as before -- sales order is at $0, no line item.

[freelock]

Hi,

Erik asked for an example BDD test for this workflow, including the scenario broken in this issue. Got a jump on this, I don't see the BDD features merged into master yet, so I'm uploading here for now rather than doing a PR... Had to add a .txt so that I could upload here...

sales-order-invoice-workflow.feature.txt

... This test is written assuming that all background data will get automatically cleaned up at the end of the test run, and that there's a COA already set up -- would probably need to add accounts at least to the parts background.

It also assumes that this is something you would run repeatedly on the same database, and so anything created needs to be cleaned up so you can re-run the tests (the last scenario will need to do this cleanup).

Lots of ways of creating usable patterns here for the text detection -- I think I used "click on button text" whereas the Drupal Extension code uses "click on" for links and "press" for buttons. And I haven't used the DrupalExtension table row selection rules enough to know the syntax they've built, but they do support this type of detecting text inside indexed table rows, or text found within the same table row...

Finally, I built these mostly around the current behavior, aside from what's actually broken. We might want to revisit this as we improve the UX, and simplify some of these steps.

Cheers,
John

[freelock]

Oh yes, you'll also see a step I use frequently: "And I save a screenshot as name"... I'm still working out just where to store these artifacts in our own testing systems, but my goal is to be able to do an image diff between the screenshots of different runs, and quickly detect if there's any dramatic layout or other visual changes, in addition to the text we are looking for in this test framework.

Internally we've started using a tool called "wraith" for this, for public pages. Am thinking about how to point this at some screenshots grabbed during BDD runs to do image comparisons for actions that require logged in users.

[ehuelsmann]

On my master-bdd-basics branch, I have a significant amount of bed framework implemented. This work can be worked on when that branch is merged. However, in having issues with that branch: for some unknown (to me) reason the last step in the first real scenario fails on traffic, but not locally.

[freelock]

Hi,

Looks like in 1.4.24 this behavior got worse. This from our AR:

1. I created a sales order, saved.
2. Emailed Sales order to client.
3. Directed back to open SO.
4. Shipped one line item by adding quantity, clicked Sales Invoice.
5. Got an invoice with no line items in it at all (completely blank, no fields at all).
6. Went back to sales order to find it closed and no previously saved line items in it at all.

[einhverfr]

fixed for 1.4.26