Announcement

Collapse
No announcement yet.

Miva Merchant 9.10.x Bug Reports

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Miva Merchant 9.10.x Bug Reports

    Please post any bugs found in 9.10.x (and 9.11.x as they'll be essentially the same release fork) here.
    Thanks,

    Rick Wilson
    CEO
    Miva, Inc.
    [email protected]
    https://www.miva.com

    #2
    I upgraded to 9.10.01 this morning. (I didn't upgrade to 9.10.00; I jumped straight to the patched version.) Now I am not able to add digital downloads to new products.

    I have tried to add a .zip file to a new product I am setting up using the local delivery method. When I upload the file, the admin interface doesn't update the Downloaded File Name and Local File Path fields as it ordinarily does. And when I check in the directory where digital downloads are saved, I don't see any file uploaded with today's date. I last added a product with a digital download on 7/12 using the previous version of Miva and I had no issues then.
    Todd Gibson
    Oliver + S | Sewing Patterns for Kids and the Whole Family

    Comment


      #3
      This isn't particular to 9.10.x but I'm not sure where else to report it (and my apologies if it's already been reported elsewhere).

      When using Amazon Pay, the customer goes through an alternative checkout flow. If there's an error (cart contents changed, payment issue, etc) the customer gets sent back to the default checkout flow instead of the Amazon one. I opened a ticket for a related issue because we're about to test an alternative checkout flow, and I noticed the Amazon Pay issue when I checked what would happen there under the same circumstances.

      So to reproduce:
      1. add items to cart and proceed to checkout using Amazon Pay
      2. get to AMAZONPAY_OPAY screen
      3. in a separate tab, open your cart and change the quantity of an item
      4. in the original tab (still on AMAZONPAY_OPAY) refresh the page
      5. you should be redirected (I think to OCST if I remember right) with a message saying that the cart contents changed during checkout
      Maybe it would be useful if there was something simple where the redirect pages are defaulted to OCST / OSEL / OPAY, but can also be modified using mvt code. Then the Amazon Pay module could define its own redirect pages on the OCST page (AMAZONPAY_OCST / AMAZONPAY_OSEL / AMAZONPAY_OPAY). In my case I could define my alternative checkout pages as the redirect pages

      EDIT: I was able to work around the issue using TemplateManager_Render_Page
      Last edited by Mike521w; 07-23-18, 07:53 AM. Reason: Added notes on a workaround
      Looking for work as of March 2024! I've been a web developer for going on 20 years, with most of that time spent on Miva sites.

      Comment


        #4
        Originally posted by oliverands View Post
        I upgraded to 9.10.01 this morning. (I didn't upgrade to 9.10.00; I jumped straight to the patched version.) Now I am not able to add digital downloads to new products.

        I have tried to add a .zip file to a new product I am setting up using the local delivery method. When I upload the file, the admin interface doesn't update the Downloaded File Name and Local File Path fields as it ordinarily does. And when I check in the directory where digital downloads are saved, I don't see any file uploaded with today's date. I last added a product with a digital download on 7/12 using the previous version of Miva and I had no issues then.
        Hi Oliverands
        We have added a bug on this issue, currently the best workaround is to create a non-admin user and assign that user the view, add, and modify privileges for both products and digital downloads. With that user you will be able to update the product with the new digital download file correctly.

        Hope this helps
        -Eric
        Eric Foresman
        Software Tester
        Miva Merchant
        http://www.mivamerchant.com/
        [email protected]

        Comment


          #5
          Originally posted by Mike521w View Post
          This isn't particular to 9.10.x but I'm not sure where else to report it (and my apologies if it's already been reported elsewhere).

          When using Amazon Pay, the customer goes through an alternative checkout flow. If there's an error (cart contents changed, payment issue, etc) the customer gets sent back to the default checkout flow instead of the Amazon one. I opened a ticket for a related issue because we're about to test an alternative checkout flow, and I noticed the Amazon Pay issue when I checked what would happen there under the same circumstances.

          So to reproduce:
          1. add items to cart and proceed to checkout using Amazon Pay
          2. get to AMAZONPAY_OPAY screen
          3. in a separate tab, open your cart and change the quantity of an item
          4. in the original tab (still on AMAZONPAY_OPAY) refresh the page
          5. you should be redirected (I think to OCST if I remember right) with a message saying that the cart contents changed during checkout
          Maybe it would be useful if there was something simple where the redirect pages are defaulted to OCST / OSEL / OPAY, but can also be modified using mvt code. Then the Amazon Pay module could define its own redirect pages on the OCST page (AMAZONPAY_OCST / AMAZONPAY_OSEL / AMAZONPAY_OPAY). In my case I could define my alternative checkout pages as the redirect pages

          EDIT: I was able to work around the issue using TemplateManager_Render_Page
          Hi Mike521w

          I have added a bug for this issue, thanks for letting us know about it.

          -Eric
          Eric Foresman
          Software Tester
          Miva Merchant
          http://www.mivamerchant.com/
          [email protected]

          Comment


            #6
            I'm seeing some odd behavior in the admin. It happened just now: a client asked me to take a look at some admin settings in their store, so I logged in, had a look, and then reported what I had seen. The client told me, no, those weren't the correct settings, and I should clear my browser cache and look again.

            I thought that was wrong, but I did log back into admin, and have another look at the page, and it was the same as I had seen before. Then I clicked the Reset button; and some of the settings changed! I'm referring to the Reset button on the page, not something in my browser (Firefox, latest version, on Windows 8). I don't think that could be a browser problem. Has anyone else seen this?

            Thanks --
            Kent Multer
            Magic Metal Productions
            http://TheMagicM.com
            * Web developer/designer
            * E-commerce and Miva
            * Author, The Official Miva Web Scripting Book -- available on-line:
            http://www.amazon.com/exec/obidos/IS...icmetalproducA

            Comment


              #7
              shipping method rules rate adjustment doesn't allow negative value (NOT shipping settings tab)

              I found on two different stores that are on 9.10.1 that

              There are two areas where you can apply rate adjustments.. one is the shipping:settings: tab and I am not talking about this adjustment which affects ALL methods in the store.
              The second is on the shipping: shipping method rules tab where you can alter the display name of each shipping method rule and also add a per method rate adjustment.

              This rate adjustment doesn't allow negative values. It should.

              I need to have 2.45 added too ALL but two methods in my store. I need to have a free shipping method and a will call available. I used the flat rate method to accomplish this. I do have a shipping:settings storewide 2.45 added to all my shipping rules. So I thought I could zero that out by going to the shipping method rule for the free shipping flat rate and setting the adjustment for that to 2.45.

              However it isn't working.

              note: I also can not just simple put the 2.45 on all the other rates in the shipping method rules tab.. because I have to do a % adjustment to all our UPS rates coming from UPS.
              So I already use the storewide shipping :settings: 2.45 and the shipping method rules % for all the UPS. That works because we only need positive values in those two rate adjustments.

              But I REALLY need free shipping and will call to end up being zero.
              I think this is a bug involved with the shipping rate methods area of the admin.

              Comment


                #8
                The product level rate adjustment can be both positive and negative. The issue here is that you're also using the Handling Charge to change the rate which is a completely separate adjustment. That handling charge gets added after any shipping method level rate adjustments.

                You can accomplish what you're trying to do with a Free Shipping Price Group. Create a new price groups and give your free shipping and will call methods a 100% discount. This discount will overwrite your handling charge for these methods and give you what you're looking for.

                I think an improvement to the handling charge section is also needed to allow for product level overrides which would have also helped in this case. I'll see if we can get this added in a future version.
                Brennan Heyde
                VP Product
                Miva, Inc.
                [email protected]
                https://www.miva.com

                Comment


                  #9

                  From your explanation.. am I interpreting correctly that it has to do with the order in which the rate adjustments are applied? And that at no time can shipping be a negative value?

                  Thus if the shipping method rate adjustment on the shipping method rules screen is applied first, and not allowed to go below 0. Even if I put a -2.45 there, on a 0.00 shipping rate, the shipping can never be -2.45, so it is zero; and then the storewide setting applies at the end which then adds the 2.45 to the shipping total?


                  product level adjustments won't help in this case. I would have to add that to every single product and every single new product in the store.. that would be insane with thousands and thousands of products which we have.

                  Free shipping can be handled with the price group. I am implementing that, we use it only with coupons anyway, so that is perfect.

                  However, we still need a will call shipping method that is $0. A few local customers are allowed to bring trucks and pickup their orders if they order over $1000 from us. Other shipping methods have to be a available to those customers though, sometimes they have us ship to a non local location instead of picking up. So I need the will call $0.00 as well as the other shipping methods to appear for those. How do I handle that?

                  Comment


                    #10
                    Originally posted by kayakbabe View Post
                    shipping method rules rate adjustment doesn't allow negative value (NOT shipping settings tab)

                    I found on two different stores that are on 9.10.1 that

                    There are two areas where you can apply rate adjustments.. one is the shipping:settings: tab and I am not talking about this adjustment which affects ALL methods in the store.
                    The second is on the shipping: shipping method rules tab where you can alter the display name of each shipping method rule and also add a per method rate adjustment.

                    This rate adjustment doesn't allow negative values. It should.

                    I need to have 2.45 added too ALL but two methods in my store. I need to have a free shipping method and a will call available. I used the flat rate method to accomplish this. I do have a shipping:settings storewide 2.45 added to all my shipping rules. So I thought I could zero that out by going to the shipping method rule for the free shipping flat rate and setting the adjustment for that to 2.45.

                    However it isn't working.

                    note: I also can not just simple put the 2.45 on all the other rates in the shipping method rules tab.. because I have to do a % adjustment to all our UPS rates coming from UPS.
                    So I already use the storewide shipping :settings: 2.45 and the shipping method rules % for all the UPS. That works because we only need positive values in those two rate adjustments.

                    But I REALLY need free shipping and will call to end up being zero.
                    I think this is a bug involved with the shipping rate methods area of the admin.
                    Hi keyakbabe

                    I don't know if this will work for your setup, but you can get the shipping method rate to go negative by using the rate adjustment in percent mode.

                    In this case you would set the price of the free shipping to $2.45 then set the Rate Adjustment to be -200%. This will get you the -$2.45 that you are looking for.

                    Hope this helps

                    -Eric


                    Eric Foresman
                    Software Tester
                    Miva Merchant
                    http://www.mivamerchant.com/
                    [email protected]

                    Comment


                      #11
                      ohhh that might just work! It's a bandaid.. but it'll work! Thanks!

                      It is so odd though.
                      if I set the flat rate method to 1.00 and the shipping settings handling charge to always, include in shipping rate 1.00
                      then in shipping method rules for the flat rate method I set percent -200
                      The shipping will appear as 0.

                      but if I use all the same settings except have the shipping method rule set to fixed -2.00
                      It shows a shipping amount of $1

                      I have to conclude the bandaid works, but the shipping method rule rate adjustment is buggy. whether % or fixed, it should work the same way and it doesn't.
                      I would also expect that the shipping method rules would be applied last. But they aren't and they are applied in a different order if fixed or percent.

                      note: Also a different bug that I previously reported, the shipping method rule display as setting isn't carried throughout the store system, it only displays on the checkout shipping selection. It should be shown on the invoice and order downloading and wherever the shipping method is displayed or is used.
                      Last edited by kayakbabe; 07-24-18, 04:30 PM.

                      Comment


                        #12
                        Originally posted by kayakbabe View Post
                        ohhh that might just work! It's a bandaid.. but it'll work! Thanks!

                        It is so odd though.
                        if I set the flat rate method to 1.00 and the shipping settings handling charge to always, include in shipping rate 1.00
                        then in shipping method rules for the flat rate method I set percent -200
                        The shipping will appear as 0.

                        but if I use all the same settings except have the shipping method rule set to fixed -2.00
                        It shows a shipping amount of $1

                        I have to conclude the bandaid works, but the shipping method rule rate adjustment is buggy. whether % or fixed, it should work the same way and it doesn't.
                        I would also expect that the shipping method rules would be applied last. But they aren't and they are applied in a different order if fixed or percent.

                        note: Also a different bug that I previously reported, the shipping method rule display as setting isn't carried throughout the store system, it only displays on the checkout shipping selection. It should be shown on the invoice and order downloading and wherever the shipping method is displayed or is used.
                        Hi kayakkbabe


                        The functionality of the shipping rate adjustment is deliberate, when using a fixed negative adjustment say -$5.00, and a generated shipping rate from say UPS this would work fine as long as all shipping rates were above $5.00. should you get a shipping rate from UPS that was only $1.00 you would end up with a -$4.00 shipping rate. In some cases this would prevent you from checking out as PayPal does not allow a negative value for shipping methods. Also, what was intended as a $5 discount on shipping has just become a $5 discount on the entire order. In order to solve that bug we put in a check to prevent a fixed negative adjustment from setting the shipping rate below $0.00.

                        In the case of the percentage negative rate adjustment, if you deliberately set an adjustment of -200% then you as the store owner are specifically asking for a negative shipping rate not accidentally getting a negative shipping rate when UPS doesn't charge much.

                        For the second issue, in my store the shipping method rules “display as” setting does get displayed on all pages during checkout and is used in admin as well. It maybe there needs to be a template change in order to see that instead of default shipping method name? I'm just using the current default framework as of mm9.10.
                        Eric Foresman
                        Software Tester
                        Miva Merchant
                        http://www.mivamerchant.com/
                        [email protected]

                        Comment


                          #13
                          The logic is sound. I am glad you explained it so I could 'get it'.

                          Comment


                            #14
                            Provisioning Issues
                            with <Product_Update code="PRODUCT_CODE"> vs way it works compared with the custom field provisioning tag and Miva 5

                            1. in miva 5, the product update code doesn't have to match on case, ie. aa716-Blue and aa716-BLUE would update the same record.
                            Now I find in Miva 9.10.1 that it does not. the code for the <Product_Update has to match.

                            2. now that the product update code has to match, it seems odd that the <Product_CustomField module="customfields" product="PRODUCT_CODE"
                            does NOT have to match and it still updates.

                            I think there is probably a bug in <Product_Update where it is now checking for a case.. when it didn't use to.
                            or if this was intentionally changed... then ALL xml import provisioning tags should check for the case on the product code.

                            however I don't think case should matter, I've been in retail for many years and it doesn't matter. the uniqueness matters on sky's. There are so many different systems, Mac, apache, Microsoft, etc. I think aa716, AA716, aA716 should all match, and use store owner should keep these very unique for each product. aA716 Aa716 AA716 should NOT be different products.

                            Here is my example I just imported
                            <Product_Update code="AA716-Blue"><cost>3.09</cost><price>10.30</price></Product_Update><Product_CustomField module="customfields" product="AA716-Blue" field="RETAILPRIC">10.30</Product_CustomField>

                            Price didn't update and store gave me error that "8-2-2018 16:35:41 24 Product_Update: Product with the code 'AA716-BLUE' already exists"
                            but the custom field DID update. And we all should expect that the product already exists as we are updating not adding.

                            this error is what I would have expected to see if I has used <Product_Add><code>AA716-blue</code></Product_Add>

                            so I suspect there is some issue with provisioning.

                            Comment


                              #15
                              Originally posted by kayakbabe View Post
                              Provisioning Issues
                              with <Product_Update code="PRODUCT_CODE"> vs way it works compared with the custom field provisioning tag and Miva 5

                              1. in miva 5, the product update code doesn't have to match on case, ie. aa716-Blue and aa716-BLUE would update the same record.
                              Now I find in Miva 9.10.1 that it does not. the code for the <Product_Update has to match.

                              2. now that the product update code has to match, it seems odd that the <Product_CustomField module="customfields" product="PRODUCT_CODE"
                              does NOT have to match and it still updates.

                              I think there is probably a bug in <Product_Update where it is now checking for a case.. when it didn't use to.
                              or if this was intentionally changed... then ALL xml import provisioning tags should check for the case on the product code.

                              however I don't think case should matter, I've been in retail for many years and it doesn't matter. the uniqueness matters on sky's. There are so many different systems, Mac, apache, Microsoft, etc. I think aa716, AA716, aA716 should all match, and use store owner should keep these very unique for each product. aA716 Aa716 AA716 should NOT be different products.

                              Here is my example I just imported
                              <Product_Update code="AA716-Blue"><cost>3.09</cost><price>10.30</price></Product_Update><Product_CustomField module="customfields" product="AA716-Blue" field="RETAILPRIC">10.30</Product_CustomField>

                              Price didn't update and store gave me error that "8-2-2018 16:35:41 24 Product_Update: Product with the code 'AA716-BLUE' already exists"
                              but the custom field DID update. And we all should expect that the product already exists as we are updating not adding.

                              this error is what I would have expected to see if I has used <Product_Add><code>AA716-blue</code></Product_Add>

                              so I suspect there is some issue with provisioning.
                              Hi Kayakbabe,

                              Thanks for letting us know about this issue, we have a bug in for it.

                              Thanks again
                              -Eric
                              Eric Foresman
                              Software Tester
                              Miva Merchant
                              http://www.mivamerchant.com/
                              [email protected]

                              Comment

                              Working...
                              X