Miva Merchant 9.00052 Bug Reports

[Eric Foresman]

Hi Ron

When you save a framework you are saving all the templates as they currently are. You can ignore the “active” column of the frameworks batchlist for now, we added that column so people doing lots of work with different frameworks would know which one was most recently applied when they have applied more than one in a day. However any framework created/saved prior to mm9.0004 does not set that flag correctly giving the impression that the default framework is still the active one even though it is not.

If you save a framework of your store as it is now and then apply it right away the active flag will be set correctly.

Hope this helps

-Eric

[harpkit]

When updating products by CSV, it does not appear the limit payment methods checkbox and limit shipping methods checkbox can be set independently. A value in either of these fields is applying to both. We limit shipping methods, but not payment methods on our site. We set the LIMIT_SHIPPING_METHODS field to 1, but after import the payment methods checkbox is activated as well. Same happens if only importing the LIMIT_PAYMENT_METHODS field, it applies to both. Tried including both columns in the file with different values, but it just sets both fields to the last one to appear. A fix would be appreciated.

I'm also gunning for a fix to this issue. My work around was to

• select all the accepted payment methods on one product
• export all products and include the payment method fields
• copy and past accepted payment methods from that product and paste in all other products
• save
• import products back in to The Miva
• Badda bing
• Badda boom

[alphabet]

Not a bug...

Just wondering why there is a template change to the PROD: Product Display Layout Tab that adds an onclick action and element to the form.

Is there something not firing onSubmit? Are there any propagation issues to be aware of?

[alphabet]

I just noticed the &mvtj.

Is the template change for AJAX baskets that will prevent/overrides default behavior?

[Brennan]

That was added to fix a potential issue where someone clicks add to wishlist, then clicks the back button and then clicks add to cart. The add to wishlist button changes the action on the page to add the product to the wishlist.

The new onClick forces the action to always be correct in the event someone uses the back button

[alphabet]

Thanks Brennan.

[josiahjg]

When doing flat file import the LIMIT PAYMENT METHODS and LIMIT SHIPPING METHODS are getting confused with each other

When doing product import of just LIMIT SHIPPING METHOD both get activated even though there is no field for LIMIT PAYMENT METHODS on file
When doing import to fix that, and just import LIMIT PAYMENT METHODS, it deactivates LIMIT SHIPPING METHODS
When doing import to fix that, importing both, payment value 0 shipping value 1, it activates BOTH

It seems the bug is if the word LIMIT is in header field it processes it for both fields not just the one

[mcrmedical]

We noticed a difference in operation that impacts our workflow, and I wondered if it was intentional.

1) Go to Order Processing. Make sure there are multiple orders in "Pending" status. Enter in new orders if necessary so there are at least two, or you will not see the issue.
2) Select any order in "Pending" status, other than the last one, and click the edit icon.
3) Click the box next to "Code" to select all the items in the order.
4) Click the Create Shipment button.

Before the update, the admin left the user on that same order screen so the user could continue processing that order. Now, the admin changes the status to "Processing" (as it should), but automatically moves the user to the next pending order (which it did not before). This does not occur if you work backwards from the oldest/last order (but we don't necessarily work sequentially oldest to newest). Disabling the filtering "fixes" this for us, but since we don't work sequentially it clutters up our list with orders that have already been processed.

This is a minor change, but it impacts our workflow (if we filter the list) Yes, we know how to work around it (not filtering the orders), so I'm not looking for ideas with this, but I wanted to point it out to see if you'd consider fixing or rethinking this.

[Rick Wilson]

Charlie,

I checked with Dev on this and here was their reply:

"There were refresh related bugs in previous versions that prevented the list from updating after the order status changed, so what's now happening is the correct behavior."

[mcrmedical]

Thanks Rick,
I can understand that. It makes perfect sense to update that filtered list. I wasn’t even aware that the list operation had changed, but I can see that now.

You might let the devs know that if you work from oldest order to newest, the sales order that is opened in the window is not automatically changed. If you work the other direction it is. It seems like it should be consistent. I’d urge to not change that order automatically in any circumstances, even though the filtered list has changed, and even though the current order open in the window is no longer in that filtered list. Changing that screen automatically to another order seems problematic, especially since the user may still be creating additional shipments for the order.

[Eric Foresman]

Hi Charlie

I am not able to reproduce what you are seeing in regards to the sorting new to old or old to new changing the way list works.

In every case for me if you are filtering the order list by status, and change the status of the order you are working on it will be removed from the list and the next order down takes its place in the viewing window.

What column are you sorting by when you see this? I was going by order id, and are there any other batch list settings you are using? How are you filtering the orders? The old style dropdowns or the new advanced search?

thanks

-Eric

[mcrmedical]

Hi Eric,
I’d be happy to share the steps. Thanks for looking at that.

I’m not speaking of sorting the list at all, but processing orders new to old, or old to new, once that list has been filtered. I’ll take you through the steps.

Functionality 1: From the Order Processing screen first filter the list to only the pending orders using the dropdown (Order Status > No Time Limit > Pending). Make sure you have several orders in pending status to see this. Open up the oldest one/the one with the lowest order number (click on it and then hit the pencil button). In our default sorting this order happened to be the order at the bottom of the filtered list. Now, in the order viewing window, select one of the checkboxes next to any product in the order and then click the Create Shipment button. The result we see is that the window stays on that order, but the list in the left column of the admin refreshes to remove the current order.

Functionality 2: If you follow the same steps, but instead of selecting the oldest order after you filter you select the newest order, the order viewing window is automatically changed to another order when you follow the above steps. As a side note, the person performing this task may still need to create other shipments in that order, or perform other operations on that order.

Functionality 3: If you filter the list using various other methods, such as filtering the list to orders in “processing status”, and shipping all the items on the order, neither the filtered list to the left nor the order in the viewing window updates. The same is true if you sort by RMA status and then cancel the RMA and re-ship the order.

So, I seem to be stumbling across a few places where the operation stayed the same, and others where it has changed. It seems to now function in three different ways, according to how you sort, and which order you process.

But we’re good at finding (and causing) problems. For now, no more filtering by order status for us, unfortunately. But when you’re considering the changes to address this (one way or another), please consider that if you make that viewing window change sometimes, and not other times, it can open way for human error. People will have to watch for different operation if they filter by status (but not if they filter any other way).

Thanks for considering our view. I hope the steps above showing where we are finding inconsistent behavior helps, even if it means making it work consistently in a way that we don’t prefer. Feel free to reach out if you need further info.

Best regards,
Charlie

[Eric Foresman]

Hi Charlie

Thanks for the info, I have added a bug to address the inconsistencies you are seeing.

-Eric

[widgetsupply]

We just noticed a big bug in our Suivant Store. It works the same way in your sample store as well.

Here is how to replicate it.

1. Add an item to the basket. There is now a number in the red basket icon.

2. Click on checkout or basket. There is still a number in the red basket icon or either BASK or OCST.

3. Go Back. The number disappears and it looks like the basket is empty. If you click on the shopping basket link, it will say the basket is empty.

I think this is affecting our Android sales as Android users typically use the back button a lot.

Thank you,
John

[Matt Zimmermann]

Hi John,

That functionality is actually a generic issue with using the browser's 'back' button. When you click the back button, in most browsers, it loads the page from cache instead of reloading the page. Unfortunately, there is no simple, cross-browser fix for the use of the back button. One option would be to edit the code to allow for the basket icon to take you to the basket page even if there is "nothing" in the basket.