Miva Merchant 10.00.x Bug Reports

[Rick Wilson]

Make sure support is aware, we're working on a fix.

[SidFeyDesigns]

Huge bug with the new 10.03.00 update.

It completely wiped every category's category tree image field.

Looks like I'll have to fill in all those fields manually, unless there is a way to retrieve what used to be in there.

[Leanne]

Thanks SidFeyDesigns! Bookmarked!

[SidFeyDesigns]

Leanne I felt the same way but maybe add this page to your bookmarks.

https://www.miva.com/forums/forum/on...plate-branches

Very helpful list of the changes you make that will be global or branch specific.

[Leanne]

Maybe I'm doing something wrong, but I just had an interesting issue while working in a template branch on the CTGY page. This was my first time unassigning content items in a branch -- the store had two instances of the category product listing (category_listing and product_list) and I wanted to start fresh, so I backed them up, and then unassigned them from the non-production branch. Previewed the page in the non-production branch, and yep, the product listings were gone. Switched the view to production and was very surprised to see that the product listings were gone from there as well. I would have thought that in a separate branch, items could be assigned or unassigned without affecting the production branch. I don't know if this was a one off or something buggy with this particular site, but that was a tad bit disconcerting.

[oliverands]

To follow up on the last post, I asked Braintree if it was possible on their end to disable 3D Secure for Discover at an account level to get around this problem. They report back that the call made by the Miva module is requiring 3D Secure on these cards--even though 3D Secure is not available for them and even though I have the module configured to only require 3D Secure if it is enabled on a card.

As Discover isn't enabled for 3DS within Braintree already, the main issue is that your integration is calling 3DS for those cards. As a fix, your integration would need to determine the card type using the information they gather at the time the nonce is created for the transaction and then selectively choose not to run 3DS for the non-3DS supported payment methods. Based on the current option you have available to you in your integration, it seems the only workaround to this particular error from our side would be to disable Discover as a payment method, at which point we could re-enable it once you have fixed the issue with your integration. If you would like to move ahead with that option, please let me know and I'd be happy to put you in contact with the team that can make that change.

[oliverands]

Since migrating to using Braintree for payment processing last month, I have noticed that quite regularly I am getting authorization failures with the message "Unable to authorize payment: Merchant account does not support 3D Secure transactions for card type." I was not able to determine what was happening with my investigation, so I reported the issue to Braintree. This is their response.

Taking a look at our logs for Errors associated with 3DS, I was able to find the error that you ran into, "Merchant account does not support 3D Secure transactions for card type." Looking at the parameters for that API call, I can see that the transaction attempt was made using a Discover card. At this time, Braintree doesn't yet support Discover cards for 3D Secure. To avoid running into error you can either avoid having customers go through 3DS if they pay with a Discover card or you can pass the threeDSecure Required field to false within the transaction sale call when someone attempts to check out with one.

Looking at an example customer who ran into this issue, customer name [XXXX], they attempted an initial transaction with Discover, but made their successful attempt with a Visa, transaction [XXXX]. As this is the case, it would seem that the errors occur with unsupported 3DS card types, but the customers then move to a valid card type that is supported by 3DS. At the current moment, Braintree's 3DS is compatible with Visa, Mastercard + Maestro, and Amex cards.

I have the module configured with the option for 3D Secure set to "Require if 3D Secure is Enabled on Card." Using this option, I would assume that if 3D Secure is not enabled on Discover cards that Miva would not be coming back with an authorization failure but would instead let the card process without requiring 3D Secure.

It appears that something in the module is not handling 3D Secure correctly on Discover cards. Or it should provide the option to enable or disable 3D Secure by card type.

[Eric Foresman]

There's been complaints in the past about the quotes module and price group pricing. I think I figured out what the issue is, and I would consider it a bug. I wrote up what I found here:

https://www.miva.com/forums/forum/on...136#post716136

Hi oliverands

Thanks for reaching out and letting us know about this. We have a bug filed for this and the fix is in testing for the next release.

Many Thanks

-Eric

[oliverands]

There's been complaints in the past about the quotes module and price group pricing. I think I figured out what the issue is, and I would consider it a bug. I wrote up what I found here:

https://www.miva.com/forums/forum/on...136#post716136

[delcorsets]

oliverands

The order remains perpetually in Partially Shipped status, and I don't see a way to manually change the status to Shipped.

We've been sporadically experiencing a similar but not quite identical issue. We use ShipStation for order fulfillment and occasionally all products will be shipped, a tracking number and cost will imported, but the order status in Miva perpetually remains as Pending. We've noticed that there is a specific kit product in the order when this happens. I've only been able to isolate 4 orders so far where this is this case, so it could definitely be a different root cause, but so far, in the orders where I've been alerted to the problem the kit is in each of them.

[oliverands]

I've just noticed something odd that may be a bug--or at least it doesn't work like I would think it should.

I sell both physical and digital products in my store. When I have an order that contains only digital products, Miva automatically sets the order to Shipped status. If an order contains only physical products, I import a CSV with shipping information, and Miva automatically sets those orders to Shipped status and saves the carrier, tracking number, and cost to the order.

But the behavior is different when an order contains both physical and digital products. For these orders Miva initially sets the order to Partially Shipped status. I can import the shipment information on the physical products, and it will save to those products in the order. But Miva does not then update the order to Shipped status--even though all items have now shipped. The order remains perpetually in Partially Shipped status, and I don't see a way to manually change the status to Shipped.

UPDATE: I just had to manually add tracking information to an order with mixed products. When I manually added this to the physical product in the order, Miva updated the status to Shipped. So it appears that it's likely only when importing a CSV with shipment information that this happens.

[oliverands]

In the Shipping Settings section of the admin, on the screen for the module Weight Table Based Shipping, when I select multiple items by placing a check mark and then choose the option to export to CSV, the file that is produced shows the shipping method names correctly, but it returns all zeros instead of the values that are stored for each shipping method.

I tested the same on the screen for Base + Weight shipping, and that produces the CSV export correctly.

[new_user2018]

Issue: Attribute Machine does not appear to be calculating prices correctly for default variants with sum of parts pricing

Steps to reproduce:

Create component part, price = $100

Create product kit with price of $150, then set up a default variant consisting of 2x component parts and using the sum of parts pricing method.

Load product page of product kit, should expect to see a price of $200. Price shows as $150. Attribute Machine appears to be correctly identifying the default variant and its components, but using the master price of the product kit rather than sum of parts of the default variant.

Alternatively, if I create a product kit with a price of $150, set up a dummy checkbox attribute, use the Inventory Kit Builder to assign the component part with quantity 2 to the dummy checkbox option, then generate variants using sum of parts pricing method, when I visit this product kit product page, Attribute Machine correctly figures out the price of the kit as $200.

Unless there's something I'm missing when setting up the default variant, this appears to be a bug with how Attribute Machine prices default variants when the pricing method is sum of parts.

[habreu]

That did it - thanks Eric.

[Eric Foresman]

It was the newest version on the apps website on 11-18-21.

EDIT: I see a possible problem. I think you may need to update the online file. When I look at the file date for the mvc inside the zip file it shows Thursday, October 6, 2016, 4:48:40 PM as the created date.

Hi habreu

Thanks for letting me know of the issue, I just got word they have now updated the link to download the new version. Please give it a try and let me know if it works now.

Many thanks
-Eric