bartervg
Automatically pause pending offers, when out of stock
Suppose I have 1 copy of tradable x and I have 2 pending offers with it. When 1 of the 2 pending offers gets accepted, it should automatically remove tradable x from available choices from the other pending offer, or cancel the other pending offer if it only has that tradable as choice.
This will help prevent failed offers, when more offers get accepted for an item than the user has in stock. If an user enable this option, It will be more important for them to track stock carefully, otherwise it will not work well.
I've been reluctant to implement automatic cancellation out of a fear of an out of control process that incorrectly cancels offers (or correctly does so, but it isn't clear to the sender why it did so). I think the danger of this automation can be reduced by adding a new status Paused. This status would prevent the offer from being accepted, but give the sender a chance to edit or cancel the offer.
Undo cancel could be useful, but it's a different issue now. The pause status requires fewer modifications.
Undo cancel could be useful, but it's a different issue now. The pause status requires fewer modifications.
really? I'd think the opposite.
Pause is in place now, but the hard part will be the logic to determine when to automatically pause an offer.
Pause is in place now, but the hard part will be the logic to determine when to automatically pause an offer.
make sure to make it optional
A simple version of this is implemented, but there are unaddressed exceptions such as handling different quantities. I opted in @Revadike and @Tecfan to test it.
A simple version of this is implemented, but there are unaddressed exceptions such as handling different quantities. I opted in @Revadike and @Tecfan to test it.
When exactly is it supposed to get paused, because I recently had offers where all the asked games became owned and the offer wasn't paused.
Offer automatically paused despite multiple copies https://barter.vg/u/49c/o/4017474/
Pseudo SQL
SELECT offer
WHERE the user's proposed+pending offer contains an item included in the accepted item
but there are unaddressed exceptions such as handling different quantities.
It doesn't look at quantity.
Also, it doesn't consider whether the item is being received or sent. Although rare, it would pause an offer where I'm receiving an item that I'm sending in the accepted offer.
When exactly is it supposed to get paused, because I recently had offers where all the asked games became owned and the offer wasn't paused.
That's because the query had a stray AND and didn't work at all.
accepted item = also chosen item, I presume?
Yes, included means that the item was chosen. included = 0 means that the item hasn't or wasn't chosen.
Another problem is that this doesn't consider marketplace items. I wouldn't want all offers with gems to be paused if someone accept an offer where I would receive gems.
Therefore, new plan is to exclude Steam items completely. Separate the queries: one for receiving items and one for sending items. For receiving items, the assumption is 1 is enough. For sending, the query should compare the tradable quantity with the offer quantity.
What did I miss?
Updated title to reflect the current proposed solution. I'm excited to see this deployed site-wide.
Before mass deployment, I think #254 Resume button needs to be working well (specifically, extending expiration upon resume), in addition #8 Bulk resume and pause would be useful. And the things holding up so much else, #19 offer preference and better implementation of preferences.
I opted in @Revadike and @Tecfan to test it.
Now opted out due to an abundance of real world testing, but not enough progress fixing the reported problems