Reverse auction

It does not support it, but it would be interesting to implement. I'll keep it in mind, but it probably won't happen soon.

I also need exactly the same feature.

I would like very much this feature, too.
I believe is just to change "High bid" to "Lower bid" and "You must bid at least" to "You must bid at max", and finally "increment" to "decrement". And, of course, a little internal logic, but I don't believe that there are too much difficulty.

If you modify the original auction module and use it as a separate reverse auction module you'll also need to modify the expiry thing. Apart from this it's quite easy to do.

I'm interested & planning to implement this feature soon. Do you prefer me to attached the module to uc_action as contrib or a new project by itself?

I've vet through uc_auction code and the API is good to use, so don't remove it =)
But I also encounter few areas where modification to uc_auction might be needed.

It's nice that you are doing this. I think a new project by itself is better. It will be easier to find if it's seperate, besides they don't exactly do the same thing. You can put a link here so we'll know where to find it.

Sorry to get everyone excited, there has been some changes of plan. Instead of reverse auction, it will be other kind of auctions, most likely along the line of unique bid auction, but I don't see why it cannot be used as reverse auction. Will update when I have more info.

I would prefer it if it were a separate project, so that people won't expect me to support your code (which I wouldn't be familiar with).

If there's any tweaks you think need to be made to the UC Auction core to make your life easier, let me know. So long as they don't rock the boat too much, I'll definitely consider them.

Work has began on unique bid auction, however I've noticed the API are more suitable for adding feature to Auction than creating a new type of auction.

Would like to initiate some discussion on some DB changes, providing the case for reverse auction & unique bid auction compare to auction

1. DB fields naming for {uc_auction} - MINOR/OPTIONAL
Current fields = nid, expiry, notified, purchased, high_bid, start_price, bid_increment, min_increase, max_increase, max_increase_pctg

auction - forward auction (with direction 'forward')
reverse - the same except in the 'reverse direction' of the bidding
unique bid - there is no 'direction', multiple bids allowed, an optional max bid cap (could reuse start_price), fields starting from bid_increment not used.

Proposed changes to give a proper picture:

2. Additional fields for {uc_auction} - NEEDED
Proposed changes:

It is possible this could enable multiple auction types on the same product? Have to dig into this, don't have this as requirement yet.

3. Misc
- Option to keep bidding history, can be handled by each auction type itself if (2) is implemented. Caching need to be implemented to improve performance.
- Reuse message notification, just wording need changes.
- Local task menu changes so other auction types can have their own configuration tab.

Will create issue to each after discussion if we agree on the changes, to keep track of patch.
Thoughts?

Ignore part of the previous post. Manage to redesign the module without any changes to uc_auction so far.

Suggestion on the DB field naming still hold though
high_bid >> winning_bid

Me too, I am redesigning the module for reverse_auctions, even if I am at the beginning.

Currently this points are similar to your approach in my analysis:

- change high_bid to something like winning_bid
- add 'type' field for auction type in {uc_auction}
- plan to keep bidding history for auctions

Differently from you, from my first analysis about how it should work, I think I will make big modifications (anyway the actual structure of uc_auctions is a great starting point) and 'type' field is mandatory.

We can exchange thoughts during work if you find it useful.

Cheers,
Francesco

I've a initial working copy of unique bid. See >> on my reply

- change high_bid to something like winning_bid
>> no functionality impact, more to easier for developer to grab an easier understanding
- add 'type' field for auction type in {uc_auction}
>> not needed actually, by adding additional table to maintain own data. A lot of retesting on uc_auction sql is required if additional field is added. By testing if a nid in our own auction table, it indicates what type of auction it is.
- plan to keep bidding history for auctions
>> there is no problem preventing uc_auction from deleting bid, but it would be nice to have the option on the ui

additional observation
1) the nodeapi load option should be re-examined for uc_auction
e.g.
start_price is needed and a required field for forward auction, but in unique bid, this field is not needed.
Current 'hack' or work around is
- add own validation before uc_auction to modify the start_price value
- override the start_price value on nodeapi load

2) the auction bid table would be nice to have api to modify it and/or extend it. Could use form_alter but the theme part is not flexible to modify, tried changing $form['#theme'] but in the case there are more modules that modify the table, it does not work nicely. I ended up replacing the bid table form with a modified version, but the con is other module modification may not work as well.