Re: [ic] IC 4.6.1 possible bug & fix for price_group feature

[Randy Moore <ramoore@axion-it.net>]

At 05:58 PM 1/13/01 -0500, you wrote:
>Quoting Randy Moore (ramoore@axion-it.net):
> > Hello all,
> >
> > I've been having trouble getting the Mix and Match feature to work as I
> > thought it should using the price_group feature (but maybe I'm
> > misunderstanding the intent here).  So, I started tracing through the code
> > of the chain_cost & tag_nitems subroutines to see what was happening.
> >
> > It appears that for the Mix and Match to work, we have to use 
> non-digits to
> > define the groups in the pricing:price_group field.  According to lines
> > 1289-90 of Data.pm in the chain_cost subroutine:
> >    $regex = $item->{$attribute}
> >             unless $item->{$attribute} =~ /^[\d.]+$/;
>
>No, this is as intended. I will admit the reasoning behind the code
>is a bit obscure...I can't remember how I documented it, but when
>checking it appears that the entire description of how CommonAdjust
>atoms work was removed from the docs. I will check on that....
>
>It is intended to operate as a boolean grouping only if the price group is
>a number.  The $regex is passed to the tag_nitems function, which if
>that is not defined (as it would be if the contents were only a number)
>then it just groups the items if they are non-zero, and exempts
>them from grouping if the value is 0.
>
>In other words, if the group is a number the only values that pertain
>are the absolute values 0 and 1 in the sense of true and false. If the
>absolute value is 1 or any non-zero number, the Mix/Match is applied,
>and if it is 0 the item is not applicable to Mix/Match.
>
>If the contents have a non-digit/non-decimal, then they can be used
>as a regex like /jewelry.*/ to group all jewelry items. If there are
>no special characters, it is equivalent to an "eq" operator.
>
>I think it is also quite possible you are being bitten by a problem
>with the field definitions in the construct skeleton (which has now
>been corrected in CVS) whereby the field type of price_group is char(2)
>and the price group may not work with some values.
>
>As I look at this, I think I tried to get too fancy. I often do that. 8-\

Thanks Mike!

I did notice the 2 character limit on the price_group, but decided I could 
live with that, especially since I had considered the groups to be 
integers.  I guess I was really just thrown off track by the example in the 
simple demo from MV 4.0.4 where you use 0,1,2,3, and 9 in the 
pricing:price_group column. I haven't checked the simple demo in the CVS 
for IC, but this might be a good place for clarification if this feature is 
still used there.

I hadn't even considered the possibility of a regex (but that would explain 
some of the code I didn't fully understand).  If I put a regex in the 
price_group column for a particular item, what fields or data about the 
other items in the cart would the regex be evaluated against?  If it was 
just the price_group column, I could be evaluating a regex against other 
regex's but I guess that would be OK.

Thanks again for the clarification!

Randy Moore
Axion Information Technologies, Inc.

email     ramoore@axion-it.net
phone   301-408-1200
fax        301-445-3947


_______________________________________________
Interchange-users mailing list
Interchange-users@lists.akopia.com
http://lists.akopia.com/mailman/listinfo/interchange-users