Miva Merchant 9.13.x Bug Reports

[alphabet]

I moved post to this thread:

I'm having problems creating a MivaPrint Q API Connection

Error
The specified API token does not have access to the following required function(s):

PrintQueueJobList_Load_Query
PrintQueueJob_Delete
PrintQueueList_Load_Query

Please add API access to the above functions in your Miva Merchant installation and try again.

But the Users > API Tokens > Functions does have the functions assigned to it.

I've tried deleting, regenerating and assigning but it still does not take.

Any ideas?

[Brennan]

Are they setup as Domain level functions?

api_functions.jpg

[alphabet]

Thanks Brennan, It worked when I set the functions as domain level instead of my store name.

Next problem I encounter is setting up the printer configuration. No print queue 'All Orders' to select even after refresh.

Where do I create a print queue to select?

[alphabet]

Found it!

Very first step Domain Settings > Print Queues > Add

[Leanne]

I'm not sure if this unique to 9.13, but I received errors when trying to batch update pricing on multiple products on the Catalog screen.

I have a site that gets that warning on certain products. The site hasn't been updated yet, so this bug has existed prior to this update.

[AHerb]

Sorry, not sure where to post, there is a typo on https://www.miva.com/template-changes page for 9.13. Search for "Instgration"

https://imgur.com/a/7Nh0i66

[Brennan]

Typo fixed, thanks!

[delcorsets]

I have a site that gets that warning on certain products. The site hasn't been updated yet, so this bug has existed prior to this update.

Brennan Is this a known bug? I don't think I've seen it mentioned on the forums before.

[Brennan]

I'm not aware of that issue, can you post the screenshot you're getting.

[Mark Hood]

My expected behavior for clicking "new order" in the admin from an old order would be that the screen refreshes to that new order.
Does not appear to be the case while a new order is in fact created. Was this on purpose?

[dcarver]

Was there any change to the <mvt:item name="urls" in 9.13? We updated to 9.13 and our url broke when any facets were applied. The url would have "Screen=%26MVTE" and thus cause the product not found page to be displayed.
The solution I found to fix this was to remove the line

<mvt:item name="urls" param="hidden_params:&mvte:global:Screen;:auto" />

from the facet layouts.
Is this a problem anyone else ran into?

Yes!!!

Change instance of

<mvt:item name="urls" param="hidden_params:&mvte:global:Screen;:auto" />

and replace with

<mvt:item name="urls" param="hidden_params:_self:auto" />

Beefy Nugget and dreamingdigital : We were able to figure out exactly what was going on in 9.13.00. The param in

<mvt:item name="urls" param="hidden_params:&mvte:global:Screen;:auto" />

is invalid and will never work as expected as we do not evaluate store-morph within store-morph. In 9.13.00, as previously mentioned, changes were made to the URLs module to drastically speedup the building of the URLs. The URLs are now built on-demand. With these changes we now support building of non-existent screens if one were to desire to do so. Thus the new module sees "&mvte:global:Screen;:auto" and breaks that into a screen of "&mvte" and the way the "hidden_params" functionality of the module works is it now has a URL pointing to "&mvte" and will output

<input type="hidden" name="Screen" value="&amp;mvte" />

. There is no bug per-se we will be filing about this. The original template written by Miva was the correct code and is what should be used in this case.

<mvt:item name="urls" param="hidden_params:_self:auto" />

and I wanted to give you an update on what exactly was going on.

[dreamingdigital]

Yup.
<mvt:item name="urls" param="hidden_params:&mvte:global:Screen;:auto" /> is readyTheme code so it's invalid from the theme itself. Might not be in any themes anymore but it was. and yup, that's not correct code but when it comes from the theme you're expecting it to work and looking at our codes for errors. Anyways, super easy fix. Takes 5min with find/replace. No biggie.

[dcarver]

Yup.
<mvt:item name="urls" param="hidden_params:&mvte:global:Screen;:auto" /> is readyTheme code so it's invalid from the theme itself. Might not be in any themes anymore but it was. and yup, that's not correct code but when it comes from the theme you're expecting it to work and looking at our codes for errors. Anyways, super easy fix. Takes 5min with find/replace. No biggie.

Thanks for that update, we'll make sure we don't use that in any future themes!

[delcorsets]

I'm not aware of that issue, can you post the screenshot you're getting.

Brennan screenshot attached

[kayakbabe]

Updating products and entering price group sale price on product edit detail.
This worked before 9.13 update. But now after the update, I can't update the product screen.

Can't update products in store admin because the store wants a subscription field to have a value in it.
I get a pop up error message that says "please enter a number"
when I close the pop-up, the product subscription block is now showing -- NOTE: I have no subscriptions set up at all.
and the cancellation allowed after ____ fulfilled orders text box is highlighted.

I even went to the modules list and made all the subscription modules inactive. After doing that, when I update a product in the admin the problem remains.

NOTE: I did try to update via the catalog:products product list first.. right after I updated to 9.13. So I don't know if the actually bug might have started there... While it appeared to accept my data entry on the all products listing screen (double click on field in row, then click save icon). None of what I entered was saved. So then I went to edit in each individual products admin screen. And that is when experienced the problem I described above. So it seems that I also ran into the bug delcorsets reported about the catalog:products and editing.

SOLN: I figured out the saleprice table for some reason has prgp_id = 0 for some of the rows. (Probably becuase I tried to create a script to do the data entry and I got it wrong the first time I ran it. ) I manually updated that zero value to the one it should be and now the errors I described above have gone away.

Psydde, maybe you have a data problem. if some key field has zero when it's expecting values from 1 and up.. that will break some things. I know I was bitten by this in the past on an older version of miva with a bad module. Maybe you have that going on somewhere.