Race condition Bug/annoyance thing.

[MyGamesShop]

Gidday,

Hope you all well...
When updating a product price/description..etc as I sometimes do while making a sale and forget to [Save] or just be unfortunate enough to be editing a sale and behind the scenes a sale is made. If I [Save] the edit then the product amount is changed to what it picked up when opening was started. This leads to incorrect stock levels for that product.

Now I know its very occasional in real life but it happens more than I would like... (If I was selling essential medical supplies this could be disastrous!! lol extreme example!)

OK I thought about this and I cant see a complete solution but I'm not that cleaver.
Could you kindly on saving ...Warn... if the there appears to be a stock level change while editing to what was picked up at the start of editing.

Total fantasy here... Maybe this could be part of a bigger warning module.. on the dashboard..
Warn if : image not available, negative stock level, (Rawi) no related products, Phoenix update.....

Endless messages.....

Mark

[burt]

It's a nice problem to have - it means you're getting sales.

It's a difficult problem to solve.

A solution, maybe, is to update your product qty in a different way; eg if you have 50 of a product and receive 20 more, insert 20 as the qty instead of 70 [this needs a change in the product adding/editing page as you would need to have the Qty always at zero when first accessing a product to update - needs coding]. Doesn't matter if any get sold in the meantime as the system will then just add 20 onto whatever number it finds in the DB [needs coding]. The $sql_data then needs manipulation to stop the update of the "normal" way that qty gets updated - [guess what, needs coding].

That's a clean(ish) way. But it would take some core code changes, for sure.

I can't think of another way to do things. I don't think we have any admin side hooks that can manipulate data in the way you need, but someone else may have other a different approach or be able to find those hooks.

[beerbee]

Hi,
this could be called a product buffer, just by letting it say when your editing a product there have to 10orso in stock counting it as zero ATM you a re working on it. Or you could just use lowest activity time on your shop for editing.. did this for for the first case way back for some stock export csv generation for resellers via cronjob.

Kind regards
Christoph

[ecartz]

I can't think of another way to do things.

We could take out the quantity from the product update page entirely. Then add a new action for just the quantity that acts like you describe, adding to or subtracting from the existing quantity.

The way to do this without core changes is a bit messy.

1. Create a new action, e.g. update_product_sans_quantity.
2. Add a preAction hook that changes the action from update_product to update_product_sans_quantity.
3. Add another action, e.g. update_product_quantity.
4. Add the interface (e.g. as an infobox) to update the product quantity.

The downside is that you have to manually maintain update_product_sans_quantity whenever there is a change to update_product in core.

[burt]

I don't think this has come up before, not here I'm almost sure, and not back at oscommerce over the past 20 odd years as well. Maybe it has, I may have missed it. In any case, it's few and far between.

Maybe, the simplest option is a user placed hook, and that one change in the product adding/editing page (for the quantity to always be zero in the input box). It just means that whoever would use this "new style" of quantity would need to remember that they have a modified file or two, so to be extra careful on future updates.

[burt]

Perhaps it makes sense to change the qty input as OP suggests. Would it be easier for the shopowner?

The only downside is that quantity inputs have been done this way for 20 odd years, would it be hard to get used to doing it differently?

[Kofod95]

The only downside is that quantity inputs have been done this way for 20 odd years, would it be hard to get used to doing it differently?

It would mean unnecessary overhead, but it could be a JS-style self-updating box. Two inputs, where one updates the other, and the value inserted is the +quantity, not the static quantity?

//Daniel

[burt]

Here's some thoughts based on my previous post;

A solution, maybe, is to update your product qty in a different way; eg if you have 50 of a product and receive 20 more, insert 20 as the qty instead of 70 [this needs a change in the product adding/editing page as you would need to have the Qty always at zero when first accessing a product to update - needs coding].

This should be really easy, simply set the default value on the qty input box to always be "0". At the moment it is either "whats in stock now" or "0". A very simple core code change, something like;

Code: Select all

<?= (new Input('products_quantity', ['id' => 'pQty']))->require()->default_value('0')->append_css('form-control w-25') ?>

The $sql_data then needs manipulation to stop the update of the "normal" way that qty gets updated - [guess what, needs coding].

This piece of data is what is used to insert/update a product, so this would need to have the the quantity part removed in some way. This could be by removing the line of code;

Code: Select all

'products_quantity' => (int)Text::input($_POST['products_quantity']),

or more interesting, by adding in a;

Hook call, and then doing code in the hook to remove that same line. It's more interesting as the hook could also be used for other addons, maybe. Not sure if any addons particularly manipulate data, but I don't know all the addons out there.

As of this point, you have stopped Phoenix from updating product quantities, even though the input (in the product adding/editing screen) still shows.

Of course, you need to save the products quantity in a different way. This is already doable without core code changes and can be done by a listener in a hook [perhaps that same hook as mentioned above!]. The PROTOTYPE CODE for updating quantity would go something like;

Code: Select all

$qty = (int)$_POST['products_quantity'];
UPDATE products SET products_quantity = products_quantity + $qty WHERE products_id  $products_id

It's actually an interesting exercise.

[burt]

The only downside is that quantity inputs have been done this way for 20 odd years, would it be hard to get used to doing it differently?

It would mean unnecessary overhead, but it could be a JS-style self-updating box. Two inputs, where one updates the other, and the value inserted is the +quantity, not the static quantity?

//Daniel

Maybe that would work very well.

I've been thinking further on it as it's quite an interesting concept (see above post) which could tie in with what you suggest.

Phoenix can already (and easily!) add data fields onto the end of the product adding/editing form or in a new tab - but I have never tried (as far as I recall!) to add in (using hook) a data field that would be next to another one (ie not at the end of the form, but somewhere in the middle). I suspect that would be doable, perhaps with javascrit.

[burt]

I've gotten it down to just two lines of pasted code (both hook calls) in two files.
One line in each file (one in the new product view and one in the update product action).

I am pretty sure it cannot be done less invasively than two simple lines of code.
Even so, not ideal, as it now makes future updates slightly harder as need to remember in which files this custom code is pasted.