News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

New pre subrelease VirtueMart 2.0.3. UPDATE I

Started by Milbo, March 14, 2012, 19:34:04 PM

Previous topic - Next topic

OpenGlobal

I have an idea.

If we can't have a bug tracker or an "official bugs" page, maybe we could have a new forum for official bugs.

In this new forum, no new threads can be created, but people can update existing threads. When a thread in another forum has been identified as a true bug, an administrator can move it to the official bugs forum. This thread with then be the definitive thread for that bug. Anybody who raises an identical bug again can just be redirected to the official thread in the new forum....

This way, the swarm can feed into a controlled forum.

OpenGlobal

Milbo

That is an interesting idea openglobl, similar to the 3rd party forum. But for now I think we should get used first to the second forum for the dev version. And we want to use the bugtracker, but not for all problems.

Just when we developing,.. we often create smaller bugs, which are fixed almost with just knowing them. For this a tracker is overkill. On the other side we have sometimes bigger bugs, we cant solve within some minutes. We will see.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

OpenGlobal

Quote from: openglobal on April 04, 2012, 18:19:33 PM
Quote from: openglobal on March 31, 2012, 15:09:05 PM
The stockable variants are still completely fubared.

Setup 1:
One parent product, price 4.99.
3 child products, X => +0, Y => +0, Z => +1

Result 1:
On the category page, the price is shown as 4.99, the base price, as expected. Click on the product, and the product flypage gives the price as 5.99, ie. the "Z" price, even though the dropdown defaults to "X".
Changing the dropdown automatically changes the displayed price back to 4.99 for EVERY variant. Even when changing the variant to "Z", the price goes grey and gets "changed" to 4.99 (ie. stays the same).
When adding any of these variants to the cart, the price in the cart is always 4.99, regardless of which variant is chosen.

Setup 2:
One parent product, price 4.99.
3 child products, X => +0.5, Y => +0.5, Z => +1

Result 2:
Similar to above except price always stays as 5.49. Basically, the prices always stays at the LOWEST variant price.
When added to cart however, the price for all variants was 5.99 (ie. the price of the highest priced variant).
One other thing that I noticed is the in the cart, the SKU displayed was the SKU for "X" for all variants, even though the description shown was correct for each variant.

This is not only incorrect behaviour, but completely unusable behaviour. Let's try to get this fixed for 2.0.3. This is basic behaviour, the more advanced custom field problems could wait until 2.0.4.

OpenGlobal

PS. There is also a javascript error given in the console when the page loads, it may be related but I haven't investigated:

"$.setproducttype is not a function"

Identical behaviour still present in 2.0.3i

OpenGlobal


BTW, "$.setproducttype is not a function" is the cause of the bug.

Fix: plugins/vmcustom/stockable/stockable.php (line 318)

Change:
$.setproducttype(formProduct,virtuemart_product_id);

To:
Virtuemart.setproducttype(formProduct,virtuemart_product_id);

This completely fixes the problem.

Any chance this could be added for 2.0.3J ?

OpenGlobal

uschmi

Coooooooooooooool !!! :)
Your solution works, openglobal!
Thanks a lot!

alatak

Hi,

QuoteFor example, the "cancel payment" bug. I received no feedback when I reported the bug, could not see any way of working out whether it was being worked on, or whether the developers had even acknowledged that it was a true bug. I got bored of waiting so spent several hours trawling through code I was not familiar with and identified two possible fixes. Only when I published my findings did I find out that it had already been fixed in the next development release.
I did it when i read your post.
I though i gave feed back, but can't find my post. My mistake then :)

OpenGlobal

Quote from: alatak on April 05, 2012, 13:25:13 PM
Hi,

I did it when i read your post.
I though i gave feed back, but can't find my post. My mistake then :)

Hehe, I forgive you :-)

This is just a symptom of the underlying problem though. The public doesn't need to be able raise bugs in the bug tracker, but if there is one single definitive place where we can read the information (eg. a read-only bug tracker), mistakes and duplications will be much less likely.

OpenGlobal

uschmi

Quote from: openglobal on April 05, 2012, 13:09:11 PM
Quote from: openglobal on April 04, 2012, 18:19:33 PM
Quote from: openglobal on March 31, 2012, 15:09:05 PM
The stockable variants are still completely fubared.

Setup 1:
One parent product, price 4.99.
3 child products, X => +0, Y => +0, Z => +1

Result 1:
On the category page, the price is shown as 4.99, the base price, as expected. Click on the product, and the product flypage gives the price as 5.99, ie. the "Z" price, even though the dropdown defaults to "X".
Changing the dropdown automatically changes the displayed price back to 4.99 for EVERY variant. Even when changing the variant to "Z", the price goes grey and gets "changed" to 4.99 (ie. stays the same).
When adding any of these variants to the cart, the price in the cart is always 4.99, regardless of which variant is chosen.

Setup 2:
One parent product, price 4.99.
3 child products, X => +0.5, Y => +0.5, Z => +1

Result 2:
Similar to above except price always stays as 5.49. Basically, the prices always stays at the LOWEST variant price.
When added to cart however, the price for all variants was 5.99 (ie. the price of the highest priced variant).
One other thing that I noticed is the in the cart, the SKU displayed was the SKU for "X" for all variants, even though the description shown was correct for each variant.

This is not only incorrect behaviour, but completely unusable behaviour. Let's try to get this fixed for 2.0.3. This is basic behaviour, the more advanced custom field problems could wait until 2.0.4.

OpenGlobal

PS. There is also a javascript error given in the console when the page loads, it may be related but I haven't investigated:

"$.setproducttype is not a function"

Identical behaviour still present in 2.0.3i

OpenGlobal


BTW, "$.setproducttype is not a function" is the cause of the bug.

Fix: plugins/vmcustom/stockable/stockable.php (line 318)

Change:
$.setproducttype(formProduct,virtuemart_product_id);

To:
Virtuemart.setproducttype(formProduct,virtuemart_product_id);

This completely fixes the problem.

Any chance this could be added for 2.0.3J ?

OpenGlobal

Another suggestion regarding this file: the width of the dropdown field for childs is pretty short - so please enhance width or, make width a configurable variable in "/plugins/vmcustom/stockable/stockable.php" line 221

alatak

Hi,

QuoteQuote from: alatak on Today at 05:25:13
Hi,

I did it when i read your post.
I though i gave feed back, but can't find my post. My mistake then


Txs to John2400. He found the post, and my answer :)
The answer is here:
http://forum.virtuemart.net/index.php?topic=100485.msg332226#msg332226
And as you can see , I did the changes the day after your post. :)

OpenGlobal

This was a different issue regarding payment cancellation.

OpenGlobal

Quote from: openglobal on April 05, 2012, 13:59:22 PM
This was a different issue regarding payment cancellation.

Yet another symptom of the underlying problem when it becomes difficult to exactly reference a specific bug that we're talking about :-)

OpenGlobal

lipes

Hi all!  Too many posts to read here today..  :P
I agree and understand  both. We have to contribute, collaborate whenever possible and be able to wait when we cant do that progress like we want/need/hope... No one is a system machine! eheh :)

So I want give to all Develop Members that keep this forum/site some suggestions (to apply or not) by fixing the tiny top #navPyra like in the image


what do you think about this?
In my opinion the fast search is crucial to have less "spam posts" (like i did sometimes.. sorry!!!) and in a fixed position will be wonderfull to users! Like the others items to draw the attention of all for Donations to Developers of this Great and Fantastic Project, and to Commercial Jobs...
I also put one link to issues... but like Milbo explained us there is no many full members that can control all list's.. So you could link to a fixed post in this forum .. but why not recruit any other member that can help with this?
this it's only some suggestions!!!

Best Regards for all And keep the good work!
VM V. online: J2.5.14 | VM 2.0.20a | SQL 5.1.70 | PHP 5.3.25

filtheetees

Quote from: John2400 on April 05, 2012, 12:26:26 PM
filtheetees,

Hi yes that is in an update or test version of VM - you can see here :   http://dev.virtuemart.net/projects/virtuemart/files

* The stable version you are using is the current version - and you are always welcome to test and trial these updates.
* make sure you back up your site and then - test.
* Joomla has also released some new versions - 2.5.4 so you can test and trial these too.
Quote from: Milbo on April 05, 2012, 12:39:39 PM

Take also a look here http://forum.virtuemart.net/index.php?topic=98648.0 , take a look on the demo in the sampledata. Thank you john for your explanation

Ah perfect.

Thanks John, Thanks Milbo.

SergioBo

can there be a way to prevent the parent product appears in the article selection.

it's really difficult to understand the current compontamento, there is a solution? we're working on?