Autobid

If you want auto bidding let me know. I've a basic one working (against a modified version of the module), but needs more refining and testing.
If G.A. agrees on reviewing it, I'll submit it.

I like to test and want help to debug the module.

Can you provide some information on what's changed and how I can get the autobid functionality?

TIA,
Fossie

Could you explain to me what you mean by "autobid?"

Autobid: when bidding on an item, the user can set
1) the bid price higher then the current bidder
and or
2) set his maximum price that he wants to pay for the item

When the user has set its maximum price, the system will bid for the user when he/she is overbid.

E.g. an item; start price $10, user A is willing to pay $50 for that item, he bids $10.50 with a maximum price of $50

When the user is overbid (another user B bids $11), user A's bid price will raise automatically with the increments specified in the admin section. User A is now the highest bidder with $11.50) ... When user A his maximum autobid price is lower then the current high bidder, no action will be taken, he is out till he / she rebids a higher price (or manually or set his new maximum price higher for autobidding).

Is it clear this way?

Fossie

It's not a module. It's a modification of existing functions of uc_auction and a modification of the uc_auction table.
The modifications were made on a previous version of the module which I adapted for another type of auction. I've ported it to the new version of the module and noticed that some parts, i.e. node/$nid/bids don't work anymore. Probably this is a views issue.

I've modified these functions:
function uc_auction_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {

I added:
$record = array(
'nid' => $node->nid,
'expiry' => $expiry,
'start_price' => $sell,
==>>>> 'mxbid' => $node->sell_price,
);
drupal_write_record('uc_auction', $record);

and:
elseif ($expiry !== NULL) {
// This is a previously-existing product which is becoming an auction.
$record = array(
'nid' => $node->nid,
'expiry' => $expiry,
'start_price' => $sell,
==>>> 'mxbid' => $node->sell_price,
);
drupal_write_record('uc_auction', $record);
}

The line numbers I have are different from the original ones, as I have modified things elsewhere

mxbid is a column in uc_auction. So you have to modify your uc_auction table by adding mxbid, as well as your database schema.

The second function to alter is:
function uc_auction_bid_table_form_submit($form, &$form_state) {
where I added the contents of 1.txt

The code is very rudimentary. Some parts are maybe redundant or can be written in another way, but at least for the time being it seems to work.

I appreciate your feedback. Only rudimentary tested for the bidding part, everything else hasn't been tested yet.

Before using, backup your data.

What the code does:
When creating an auction it inserts the initial price as max. bid value. Each subsequent bid will be tested against the conditions layed out in lines 7xx and if the bid is higher than the current max.bid it will update the latter.

BTW: if the original author doesn't support it, you'll be pretty much on your own as uc_auction is still in development and things can change considerably.

Ah, I get it. eBay-style bidding.

I intentionally didn't implement this (or reserve prices) for one, because I wanted to avoid the extra complexity compared to implementing a more straightforward bidding system, and two, such tricks can be annoying and confusing to those unexperienced in online auctions. That being said, I'm not against others implementing it.

I'd really like to see it be done as a module instead of tweaks to the original code, though. But in order for that to work, I'd probably need to sprinkle on some API to uc_auction. Maybe something like hook_bid_submit(&$node, &$bid)… Should I go forward with that?

Hmm, yes if you name it like eBay-style bidding, that's more or less what I mean. Maybe that hook should do, so another module can benefit and interact with uc_auction.

It's not that I'm planning to build an eBay clone, it's for bringing assets online with only professional buyers and I think they don't want to bid, re-bid, and so on. It's like they are willing to pay a certain price for an asset (or less the price of course).

But maybe we should wait till the database scheme is more or less stable.

Anyway, thanks alot,
Fossie

You don't need to, unless someone else is interested in writing a seperate module; for the time being I won't. On the other hand, if it's not too much work for you, I don't mind you create those API's. I can still look at it later.

I think a seperate module will add unnecessarily complexity to the case. a.o. requiring two or more queries to be run instead of one.

I initially implemented it for a dutch auction and tried by using a seperate table. I finally settled with just adding a column to uc_auction, because this was easier to implement.

For the record, I'm heading on vacation tomorrow and won't be back for a week. But when I'll get back, I'll push some dev code with some initial work at adding API goodness.

It's later than I was planning, but I just pushed an update which has some initial hooky goodness. The three hooks available at this point are hook_auc_expired($nid), hook_bid_alter(&$node, &$bid_record, &$auc_record), and hook_delete_bids(&$node, &$to_delete). Check out uc_auction_api.module in the new uc_auction_api directory for (what should be) extensive documentation on how to use these.

I've tried to think of other hooks that should be added, but I haven't really thought of any, save perhaps for a hook when a node becomes an auction or un-becomes an auction (without being deleted). Can you think of any that might be helpful?

Consequent to adding these hooks, there's also some general code improvements. I can't remember them all, but deleting bids is handled in a smarter way now - that much I remember.

Thx for your good work, I'll check out tomorrow or the day after and let you know what my thoughts are.

Fossie

Fossie, have you had a chance to look at this yet?

No, but I'll start on this tomorrow.

Maybe the idea (buy it now) on storing the high bid price in a separate field, is a good thing, should I wait or can I go with the dev version of 20th of December.

Fossie

Hello Garrett,

First of all, happy new year.

You have created the hooks (I've checked them), but what in your opinion is the best way to use them to write the autobid module?

I'll try to write up my thoughts tomorrow.

Fossie

The key is probably hook_bid_alter(), which will be called whenever a bid is placed. If a new bid is under the autobid value of an earlier bid, the new bid can be "cancelled" by having your implementation of this hook return FALSE. You'd then want to adjust the current high bid value (or possibly insert another bid) to match the value of the failed upbid.

Come to think of it, you may want to hold off on your work until the next CVS update, because it's going to make some big changes to how the current high bid value is stored and loaded, as I mentioned in the "buy now" thread. (It'll also change the DB schema again… sorry.)

I see, thx.

I was just thinking about this scenario:
- a user can (with a checkbox for example) choose to place a bid or his maximum bid

Let's say:
UserA: had the current high bid of 200 and a max bid (auto) of 500 for the product

UserB: tries to bid 230 (one shot), I think the system should not warm him directly, because otherwise no-one wants to bid anymore if he knows the price is too high).

Thus: UserB can bid 230 and when submitting (for example) the lowest autobidder places a new bid; 230 + the increment mentioned in the system. This will repeat until the highest autobidder has placed his bid and UserB is shown that he is outbid with that value. I'm thinking how to make it fair for all parties, but directly showing the highest autobid value is not good, due not bidding anymore).

Now UserB knows that he is outbid and can place a new bid or leave it.

The other way: when UserB has placed (with the checkbox) that his bid is an autobid (max bid of 400), the maximum price he is willing to pay for the product, his bid follows the same way; current bid + increment, look if their are autobidders; take the lowest first and increment with the system value.

First look at the one shot (current place bid), secondly see if their are users with autobid (max bid), prcess them from lowest max bid to highest (take the system increment value for price raises).

Is this explaned more or less well? Can this be done in the alter function?

Another thing; when do you think your new, modified dev version (cvs) will be available?

Anyway, thx,
Fossie

Is this explaned more or less well? Can this be done in the alter function?

With other code, yes. But I think the alter hook is the key to getting your code to interact with mine in this regard.

Another thing; when do you think your new, modified dev version (cvs) will be available?

I can't make any guarantees. Hopefully some time this week.

Thx, if the new cvs version will be out this week, I can wait to try to make the new module, if the version will be ready later, I'll have to start now.

(question was just to know, not to put push you)

TIA

@fossie,
You can have a look at #5, file 1.txt. It does ebay style bidding. the code is, however, very rudimentary and modifies hook_nodeapi(). However I think that you will have difficulties doing subsequent bids, unless you insert bids directly from your submodule into the bids table (in which case I don't see the benefit of having an autobidding feature implemented into a separate module, except for convienence of maintenance): e.g.
The current mxbid= 500 (uid of mxbidder=1)
The current displayed bid=300 (uid=1)

If a user, uid=2, bids 350, the bid insertion will be:
curr.bid=300 (uid=1)
new.bid=350 (uid=2)
overbid=350 (uid=1)

So the new displayed bid will be 350, but in the bid history you will see that uid=1 is autobidding. What you can't see is what his max bid is.
If, however, you don't show that someone is autobidding, people might think that the system isn't doing things correctly.

In terms of storing the max. bid of a user: You can use a seperate table, by creating your own database schema that accompanies the submodule.

That new table can store things like:
nid, uid, time, maxbid, ...
were:
nid=node id
uid=uid of the max.bidder
time=time the bid was created
maxbid=the maxbid.

@pndur
Thx, I already looked at #5, the addition to the table and the 1.txt file, but then I had to use the hook_nodeapi(...) iso hook_alter.

Was it just a type mistake or is this the real implementation?

If a user, uid=2, bids 350, the bid insertion will be:
curr.bid=300 (uid=1)
new.bid=350 (uid=2)
overbid=350 (uid=1)

the overbid should be 350 + the increment, no? Otherwise it isn't usefull to bid on an item when a user has an max high bid of 5000 for something is worth 100. In my opinion, the autobid should be on top of the bid inserted by user 2, no?

The user (uid == 2) should see that he is outbit but not with the price he entered, or is my idea wrong?

Fossie

@fossie

The example mentioned in #20 is the case when there is a max.bid already entered and stored in the table from a previous bidder, who is currently the highest visible bidder in the bid history. In this case there can be a couple of options a.o.:
1/ the new to be submitted bid is less than the current max.bid stored in the table (this is the case described in #20).
2/ the new to be submitted bid is higher than the current max.bid

In case 1 defined increments will not be applicable. In case 2, they will.

But even in case 2 you'll have subsequent bid insertion in the table. e.g.
current visible bid=200 (uid=1,), max. bid is=300 (uid=1, stored in max.bid table)
new bid=350 (uid=2)

Bid insertion and bid history will be:
200 (uid=1, currently visible bid) <= bid already inserted
300 (uid=1, currently max. bid) <= new to be inserted
300 + bid increment (uid=2) <= new to be inserted

max. bid insertion in the max. bid table:
300 (uid=1, currently max.bid) <= bid already inserted
350 (uid=2, new max.bid) <= new to be inserted

The bid increment can be hardcoded, like in 1.txt or you can get it from variable_get ('variable', XXX)

The user should see that he's outbidded by someone else. The only way he can see this is by inserting those bids twice like in #20 (in case the new bid is less than the current max.bid). Or in case when the new bid is higher than the current max.bid you'll get the example above.

Thx Pndur.

Ok, I think I understand your point, this maybe also important when the admin deletes (for some reason) a sequence of biddings (bid history). This must also be triggered.

I was a bit confused due the max auto bid of 500 for user 1, current 300 (uid 1), new bidder 350 (uid 2) and he was outbid by uid 1 with 350. Once I start, everything will be clearer (I hope)

I didn't start writing the module, I'll wait till Garrett finishes the new cvs version.

I just pushed the new version. Have at it. Some of the new stuff is pretty raw, though.