Bug found in orders page v 5.2.8 - unable to chage status in bulk

[ian_tttt]

On the orders page http://demo.cubecart.com/cc5/admin.php?_g=orders the bulk edit is not working.

 

To replicate click on multiple boxes and try printing multiple invoices - nothing happens

or

change status to complete - noting happens.

 

using IE 11 and also tried compatibility mode.

 

PS now the bug tracker is missing/closed to public where is the correct place to report bugs? apologies if this is the wrong place.

[bsmither]

Devellion will suggest a Sales Ticket (that's where I report my bugs).

 

But in these forums is nice, too. That way, all of the CubeCart Community will be aware of the issue and may be able to contribute a tuppence or two.

 

Devellion should notice the post, and hopefully will finish the thread with what was discovered.

[havenswift-hosting]

Devellion will suggest a Sales Ticket (that's where I report my bugs).

Strictly speaking a sales ticket is only for pre-sales enquiries. When you purchased your CubeCart licence it would have come with a number of free support tickets so if you log in into your account at http://cp.cubecart.com you will then be able to use one of these to log a ticket - if what you report is indeed found to be a bug, then the ticket is credited back to your account (they take the view that it shouldn't cost you to report a bug in the software !)

 

But in these forums is nice, too. That way, all of the CubeCart Community will be aware of the issue and may be able to contribute a tuppence or two.

I agree with Brian that it is good to have a record of true bugs in these forums to make a public record that helps other users - however, I believe the best way is if a reference to the github issue submission is published showing the fix. That way people can use the source code changes that will form part of the next release rather than possibly have a customised "fix"

Thanks

Ian

[bsmither]

Specifically, my CC527 returned this to the browser:

302 Found hllp://www.example.com/admin.php?_g=orders&print[0]=<order_id_0>&print[1]=<order_id_1>

 

Where the demo CC528 returned this to the browser:

302 Moved Temporarily ?_g=orders&multi-order[0]=<order_id_0>&multi-order[1]=<order_id_1>&multi-status=&multi-action=print&go=Go&search[order_number]=&search[search_customer_id]=&search[status]=&search[date][from]=&search[date][to]=&token=15a97eb5771414cb7bb7f17c4ef735ab

 

It seems the demo store is simply returning the POST as a URI. The browser then sends that off back to _g=orders, where the GET array is ignored.

[bsmither]

In the file /admin/sources/orders.index.inc.php, there are new statements at lines 7-9.

 

If POST['search'] is set (which it will always be because there are array keys - although probably all values will be empty if no search is being made), POST gets converted to a querystring and sent back to the browser -- whereupon the browser makes that page request.

 

Later in this file, all the code that parsed and built the SQL query was changed to look at GET (was POST).

 

So, if the reason was to catch and deal with the search request (separately from the POST), if one was present, this solution broke the page.

 

Perhaps we need to determine what has priority: a search or a bulk update. Actually, it probably does not come down to determining a priority -- if wanting a search, the checkboxes (form element 'multi-order[]') and the Go button will likely be empty or non-existent in POST, and if wanting a bulk update, the Search Orders fields will likely be empty.

 

Therefore, lines 7-9 might work better as:

if(empty($_POST['go'] && !empty(array_filter($_POST['search'],'strlen')) {
    httpredir('?_g=orders&'.http_build_query($_POST['search']));
}

If POST['go'] is empty, we are not doing a bulk update. And, if POST['search'] (examined for any non-blank values) is not empty, then go do the search.

 

But if POST['go'] has a value (the Go button clicked), then don't do the search.