Ubercart

There are now three conditions (order total, product, and role) and two actions (discount from order total, discount products). Discounts are now seen on the checkout screens and do indeed get stored as part of the order. The Discounts contribution description has been updated, and a new file attached.

The file is not in gunzip , but in bunzip

Force of habit. Reattached in gzip now.

thanks a lot marshal. I think I would like it.

But I get following errors after adding a new discount:

I'm too tired for checking the reason this night. Do you have an idea what wents wrong?
thanks.

This error is because you have no conditions defined, resulting in $condition_list being NULL. I'm uploading a new version which fixes this for conditions and actions.

Great work marshal!
Thank you!

Some annotation:
- It would be cool, if the discount could be displayed at the shopping card.
- Like descriped in this thread: http://www.ubercart.org/forum/development/224/strange_behavior_hook_line... there's a problem with the set_line_item() function.
- I think it's better to group all modules (main and submodules) together (Otherwise people like me wondering, why they can't define conditions

I agree with michels, you've done a great job with this module. I get a strange problem though - but it may be a result of my previous code "tweaking" of the other modules

Problem: After sending an order (with all correctly calculated values) I go to: admin/store/orders and get this warning: Invalid argument supplied for foreach() in /modules/ubercart/uc_discounts/uc_discounts.module on line 370.

Further more total sum is incorrect there. Sth like this:
Subtotal: 755,81 zł
Shipping Cost: 0,00 zł
Rebate: -113,37 zł
Total: 755,81 zł

Can you please help? Greets from Poland

I just test on a new drupal/ubercart/discount installation, and when I purchase a product, and then to display the order I have the following error :

argument supplied for foreach() in /modules/ubercart/uc_discounts/uc_discounts.module on line 370.

foreach() can handle empty arrays, so what that's saying is that $cart is not an array at all. Looking over the code for uc_cart_get_contents(), this should not be possible.

The following adds a check for a cart which is not an array or is empty, for debugging purposes. It would be helpful to see if either of the messages below display when you get the error.

--- uc_discounts.module (revision 19)
+++ uc_discounts.module (working copy)
@@ -366,6 +366,16 @@
}

$cart = uc_cart_get_contents();
+ if (!is_array($cart)) {
+ drupal_set_message('Bad cart - is not an array.');
+ return array();
+ }
+ elseif (empty($cart)) {
+ drupal_set_message('Cart is empty, no discounts will be applied');
+ // nothing in the cart? no discounts
+ return array();
+ }
+
$cart_copy = array();
foreach ($cart as $cart_item) {
$cart_copy[] = drupal_clone($cart_item);

Marshall,

Is there any way to offer discounts based on a group of products. ie I would like to offer 10% off the purchase of 3 or more widgets from category X

I tried to remove a test discount I just created, and when I go to edit, and press the delete button, I just return to discount listing and the deleted discount is still here.

Am I alone to have the problem ?

zmove

this problem, as well as the one described above, are likely a result of running alpha7c code without appropriate changes to uc_discounts.module to account for the updated checkout panes for alpha7c. Here's a patch which makes uc_discounts comply with this API change:

Thanks for the patch, it worked great. This was top on my list of things to do today, and you just made it a whole lot easier.

has the original .gz file been updated with this too?

Hi there,

I'm posting here to speak about the integration with taxe system.

In the note below the module description, it says that the module is not well tested with taxes.

So I test, and it doesn't work.

I will try to make it compatible, The best way would be to add a checkbox in the tax module to check or un check if you want to apply taxes on the discount.

I made uc_discounts module compatible with uc_taxes module.

However, when you think about how tax have to be applied, you can easily conclude that the uc_taxes module have to implement uc_discounts and not uc_discounts that have to implement uc_taxes.

Why ? because taxes is a thing that have to apply at the very end of your order. When you calculate a discount, it have to apply to an excluding tax amount and, then, tax have to be calculated on the new price without tax. That's why it's more easy to understand and to implement in the uc_taxes.module than the uc_discount.module.

So I created a patch of the Alpha 7c uc_taxes.module. This is a very little and easy to understand patch.

I only changes some lines in the uc_taxes_calculate($order) function to substract the discount amount to total before calculating taxes amount.

It could be really great if uc_taxes.module could implement the uc_discounts inrtegration in core, to not be obliged to modify it each time an update is made.

This is the patch content

zmove

I get the error "Fatal error: Call to undefined function: uc_cart_checkout_new_pane() in uc_discounts.module on line 249" when checking out, any ideas?

I really need this module to work!

Yes, just apply the spiderman .diff....

zmove, I don't really want to make a special case for discounts in uc_taxes because it already handles line items in general.

I looked into the discounts module because I thought that they were added as line items, but I think I know why taxes aren't able to pick them up. Firstly, uc_discounts doesn't implement hook_line_item(). This prevents Ãœbercart modules from knowing that discount-type line items exist. Secondly, the discounts are applied to the order during the 'review' step, which is after the taxes are calculated in the 'process' step.

If someone could roll up a patch to do that, I think that'd be the best solution.

Thanks for your answer Lyle. I will try to modify the discount module, because I don't like to hack core, and if I hacked the uc_taxes.module, it's because I thinked that there were no alternatives.

Correct me if I'm wrong, but by looking through the code, I noticed that the tax module calculate the taxes by calculating the tax rate for each product. See this code in uc_taxes_calculate() that is called by uc_line_item_tax()

So even if the discount module use the hook_line_item, I don't know if the tax module could correctly calculate the tax (maybe I'm wrong, I'm far to understand all drupal and ubercart behavior so, maybe I need more explanation ^^)

For the last point, I don't understand you Lyle, you say that the discount is calculated on the review step.. what do you mean by review step ? the order review page ? Because the discount module show the discount amount on a checkout pane, so I don't understand well what do you mean by review step.

regards,

zmove

The function that builds the checkout pane gets an $op parameter. This parameter has three valid values: 'view', 'process', and 'review'. uc_discount_checkout_pane() only uses 'view' and 'review'. What it should do is calculate the amount in 'process', and then display it in 'review'.

The tax on the discount might be off, but only for discounts on particular products. Discounts to the order in general will also discount those taxes that apply to the discount line item. However, the tax rules can't distinguish between discounts on specific products like they can distinguish between product types. Might have to make a hook to deal with that somewhere.

After some test and some modification. The tax is well applied after the discount but only on the order review page. the tax is not well applied on the checkout page.

Lyle, you seems to say that the discount is calculated on the order review page, so I tried to put the discount calculation on the 'process' case. But it changed nothing, I already try to put the discount in a hook_line_item but it didn't change the checkout payment pane and it add an extra discount line to the order review page.

I upload the discount.module I obtain after a day of testing... My brain has reached his limit without succes...

After some tests, I noticed a strange thing.

the Taxe don't apply on the payment checkout pane, but, if you choose your address by selecting it in the dropdown menu (when your address is saved). The Tax is recalculated and take care of the discount amount.

very strange.

I apologize for my absence from this. Unfortunately, our sponsor had a staffing change a while back, and decided to go in a different direction. As a result, it's difficult for me to keep up with this and work on the Discounts module. We are, of course, open to other sponsors.

I need working role discounts for my project now - with user friendly display on checkout page:

I am able pay for it some money, but I am afraid that my resources are not enough But I can post you a lot of super Czech beer
//sorry for my english

I've never had Czech beer.

I need to get this going as well. I just have a couple things on my list first.

the following is a patch that may be relevant to others using this module. it "fixes" a number of things in the module (whether they are "real" bugs or not- they didn't work the way we needed them to), and adds support for discounts based on product classes, in addition to individual products.

the core infrastructure of this module seems very solid, although there were a few issues (mostly covered in zmove's helpful post, many of which are addressed in this patch. one of the basic requirements we had, however, was to be able to apply discounts to all products of a given class.

this revealed some of the limitations of the extensibility framework that marshal has begun. overall, i think this framework makes a lot of sense, but a) doesn't cover enough cases, and b) has a few inherent limitations which are hard to address with the conditions/actions approach (more on that in a moment).

so first off, we added some support to the uc_discounts.module itself to allow for non-integer-based "items" to be provided by the sub-modules. in this way, we could add a uc_discounts_product_class.module (an initial implementation of which is included in the patch) which would allow the user to choose a product class for both conditions and actions, and thereby allow multiple products from the same class to "count" toward a given discount.

the rest of the patch to uc_discounts.module itself is mainly fixing a few logic errors and implementing the full range of operators. patches to uc_discounts_product.module effectively clean up the internal logic of single product discounts to conform to the needs of our clients (again, i'm not 100% clear what the original intention was here, but it didn't work for our needs, at least). apologies for the various debug messages in here, although maybe they will help understand what is actually going on in the dark corners of this module

the one limitation i found in working with the new product_class module was that it seems tricky to provide conditions/actions that can be used independently of each other. for example, when i first went to build a per-product-class discount module, i thought i should be able to simply provide a new type of condition, and use the existing per-product action to actually apply the discount. however, in practice i found i couldn't get this to work, because the actions callbacks seem to rely on the conditions, and vice versa. it's possible this can work, but i couldn't find a way.

beyond that, one of the things we'd like to have from a discounts module that it's not immediately obvious how to achieve with the current framework is the ability to show the user applied discounts at the product level. for example, if you buy a lot of buttons, you get them at a discounted rate. at the moment, the total discount is calculated and displayed in a separate table, but it would be nice to show the customer what the discount is per-button, in the list of products on the checkout/review order pane. this way, they could see immediately how much the buttons are costing them, without having to do the math (regular price shown in list - discount shown in separate table).

as always, feedback is appreciated, and hopefully all of this is of use to somebody. i've no doubt we'll be revisiting all of this stuff in the not-too-distant future, as ubercart evolves and our requirements grow

following on from my previous comment, this patch adds support for discounts which apply to combinations of products/classes, and also implements a new "amount" field which allows for defining an additional conditional: if the product in question's sell_price is equal to the "amount" field, then it counts towards the discount.

the first piece of this is to allow for discounts where if customers buy a certain number of either buttons or stickers, in combination, then they get a bulk discount. i accomplished this in a somewhat hackish way, by extending the "items" field in the conditions/actions table to store a serialized array of products/classes, and treat them appropriately when considering whether a given order should get a discount.

this approach seems less than ideal, and i imagine that in a perfect world we could define any number of products/classes which would match a given condition/action. these should really be stored in a separate table, so that one could say "any combination of this particular product and this class of products should receive a discount" (at the moment, you can only choose a product *or* a class).

the second thing this patch does is to provide an "amount" field on conditions, to allow for selecting products/classes with a specific price. this allowed us to restrict discounts to only "regular priced" products, and not apply them to "on sale" or package products within a given class.

this feature is mostly working, although i've had a couple reports in the last day or so that something's not quite right and discounts are sometimes being mis-applied (still trying to track down this bug).

once again, any and all feedback is greatly appreciated, and we hope this code can be useful to somebody, especially if it contributes to increasing the usefulness of this module for the community at large

I've implemented a slightly different approach to the same problem as described by zmove, and though it's not ideal, i thought i'd post it here for completeness:

Importantly, this approach avoids calling uc_discounts_apply_discounts, which seems to do strange things when called more than once on a given order.

As suggested by Lyle, I think this is probably better accomplished by having uc_discounts properly implement hook_line_item, so that taxes can (optionally) apply before/after the discount amount is considered.

This is exactly what I needed to make this module work, thank you.

Is it possible to post final version of discount module file, with all those revisions applied? I would really appreciate, because I badly need this working, but I don't know how to apply all these diff files. Thank you very much.

Hey guys - anyone have the complete module? I tried applying the patches and I keep getting Hunk failed, malformed patch, missing header, etc etc. Nothing seems to be quite right.

If someone can post the complete tarball I'd be much obliged

I too would greatly appreaciate a working tarball. I went through and tried to apply the various patches. None of them apply cleanly, and based on the two hours of bug hunting I've already done, it appears that those that did run, often applied themselves into the wrong place. If I do manage to get it working, I'll gladly post what I have to this thread.

Here's what I have. Not sure it's 100% functional, but I got it to a point where it's not generating parsing errors anymore.

Thank you for your repackaging surge_martin.

I tested your files and noticed several errors :

• Impossible to delete a discount, when you make delete, the discount is not removed
• I cant add conditions to a created discount, it say : "Amount must be a number"
• I can add actions, but they don't apply, in fact, discount is never applied

So, in fact, I have no error now, but nothing works.... I'm on alpha 8, maybe it need an integration with workflow... don't know.

Humm,

Just testing this for a future project:

For me anything post the year 2037, flags the error 'End date can not be before the start date'?

Also, maybe 'Setting the end date in the past is pointless.' should be changed to read better to clients... sorry to be a stick in the mud!

Not as good as the message on the tax module though - 'Misusing this field can really mess up your site. DO NOT BE STUPID.' - genius!

Anyway, back to my actual point; I too have the errors listed in the post above as well as the end_date error I have mentioned.

Is this to do with the repackaged file by surge_martin, or do I need to apply any patches for 7e?

Many thanks

Paul

I sent spiderman a PM asking for a most recent module, but haven't heard back yet. I'm hoping someone has the most recent / complete module that we can take and continue developing from.

Same problem, on alpha8, discounts gets never applied even with the most large condition possible.

I'm thinking of getting back to alpha 7e because I NEED working role discounts.

I'm looking at getting a discount system going that uses Workflow-ng. So far it's looking like the discounts will be applied as items are added to the cart. This means that the product pages won't show the discount, but they'll see the difference in the shopping cart. Advertising the discounts in the product body or in blocks around the site should encourage customers to take advantage of them.

Sweet! What's your status on that? Right now we're using a Product Kit to allow discounts on products, but some people are confused in thinking that, if they add the components one at a time, they'll still get the discount (which obviously is not the case at this point). So a discount system that allows for this type of functionality is wholly welcome.

I agree with Lyle, we have to don't forget that the discount is a marketing tool, so the customer have to see them in product node discounted body, not only on the cart or checkout.

What's the status of the module? I would be willing to help pay to have this module working with some new features ASAP. Anyone up for some paid programing?

Hi
I got the role based discounts working. I'm using alpha8, and the uc_discounts.zip posted by surge_martin..
Since I just picked this package up, I don't want to mess up the code conduct or anything like it..
Just thought I'd post my discoveries, and see what Lyle or any other maintainer says. Also has to be said that I only need role based discounts, so none other tested.

1. The uc_discounts_condition_form_validate in uc_discounts.module, first lines is a numeric check on form value prop, this is not valid for the role condition, which doesn't have a value.
2. uc_discounts_apply_discounts() in uc_discounts.module, there is a foreach loop that checks operators. Now this thing kills the role condition: if ($c == 0) { $condition_groups[$i] = FALSE; } It does so, because role discount doesn't include a count_check. That leads to this test never passing: if (array_search(TRUE, $condition_groups) !== FALSE) {

Now after fixing those problems, the condition kicks inn, but discounts pane is never added to the checkout.
I fixed that by adding a separate products based action with a apply_callback to the role discount..But that is probably not the way it was intended. I'll look into that some more.

Edit:
Looked into it..
It looks like the sql statement in uc_discounts_product_apply function in uc_discounts_product.module doesn't fit the role discount need. The products are actions if it is a role condition, so that statement makes the condition_list empty, and the function returns 0, hence no pane.

If anyone is interested in diffs, lemme know(need to remove debug statements).

Anyways thanks for an uberproduct!!

cool, working fine. What I'm missing is a module that grants discount on how many articles purchased.

Can you post a patch with your changes? Thanks!

I've tried to leave this code somewhat better than how I found it ...

Here are my changes since surge_martin's version:

This version installs and runs on a site with Ubercart alpha 8.

Not sure why, but the only options that appear after install are to set user permissions. There is an empty bullet that appears in the Customer admin section. I'm guessing this is where the admin options would be, if they appeared.

Any ideas?

Thanks.

Thank you detour, I will try your discount improvement on a sandbox and I will give you feedback.

Hi,

I'm having similar issues with the Admin options.
The link shows it pointing to http://localhost/shop/admin/store/discounts/valuehtml

but I can only get to it by going to http://localhost/shop/admin/store/discounts/value

Here is a picture.
http://img253.imageshack.us/img253/4350/discountsyw4.jpg

(The discounts menu item there is one I made manually)

Other than the link/menu stuff, it works great!

Thanks for the reports back.

I'm attaching an updated version of uc_discounts that fixes the store administration path issues. The valuehtml path seems to be from a deprecated/incomplete feature. I've removed it and made one other small improvement to the menu code.

Also, I've corrected two lines of code that relate to showing the discounted price on the product's page.

Let me know if this resolves the issue, and if anything else comes up.