[ic] products using inactive

[interchange-users@icdevgroup.org (Mike Heins)]

Quoting Barry Treahy, Jr. (Treahy@MMaz.com):
> Mike Heins wrote:
> 
> >Quoting Barry Treahy, Jr. (Treahy@MMaz.com):
> >  
> >
> >>Philip S. Hempel wrote:
> >>
> >>    
> >>
> >>>Just befor I pull my har out, does the usage
> >>>of the inactive function through interchange
> >>>or is it built by me into the webstore?
> >>>
> >>>I don't want to start off looking in the
> >>>wrong location to make this work for
> >>>me
> >>>
> >>>      
> >>>
> >>I just did a grep on the sources for the key word inactive and with the 
> >>exception of the UI for customers, I saw nothing so my initial guess is 
> >>that it would be a feature that you would need to build into your site...
> >>    
> >>
> >
> >You won't find that many hardcoded field names in the IC core. Almost all
> >that are there can be remapped.
> >
> Good morning Mike...
> 
> This is meants as a learning question for me, not to 'question' you; But 
> if there is a fielded defined in a table, that is instrumental to the 
> logical or processing of IC, then at one point or another would there 
> not have to be a hard coded reference to that field, be that in IC or 
> one of the Vend libraries?  Putting aside the inactive column and 
> looking at something more fundamental like price for example?

No. It does not have to be hardcoded at all.
> 
> My reason for asking is that I often grep the core program and libraries 
> to try and better understand how a field or tag might interact and 
> relate to other actions in IC.  If this approach is flawed, what could 
> you recommend to aid in the Q/A process so that folks like me that are 
> in a 'perpetual' ramp up on IC don't have to bug the list frequently 
> with what might otherwise be considered mundane or novice questions?

There are usually hardcoded defaults, but you will mostly see this type
of thing:

	my $cfield = $opt->{country_field}
		   || $Variable->{MV_COUNTRY_FIELD} 
		   || 'country';

In the case of the special price and description basic to all ecommerce,
those are directives:

	DescriptionField    description
	PriceField          price

You can set them to whatever you want.

When there are lists, like in the Vend::Payment stuff, you will
find a remapping facility:

Variable  MV_PAYMENT_REMAP   <<EOR

	address=address1
	province=state
	ctry=country

EOR

Much of this behavior is documented.

> >There is a new feature in IC4.9/5.0, called HIDE_FIELD. It automatically
> >blocks records where a field contains a true value for searches and such.
> >
> Perhaps you could expand on this further?  Blocks fields, or entire 
> rows?

You need to read the WHATSNEW file.

> This could be extremely useful as some products that we list can 
> only be seen by US customers, others only by International customers, 
> yet the standard search could find both on the same search.  A crude 
> example that really doesn't apply to our products but presume prior to 
> switching power supplies, you could have two blenders, one at 120VAC 
> 60Hz and a second at 240VAC 50Hz.

> To show both could create confusion. 
>  In our case, I have four new columns in our product table that searchs 
> must use to include/exclude records depending on who they are:
>  allow_us        allow_uk        allow_intl      allow_disty

That is the type of specific custom function best handled in your
catalog logic with the [query ...] tag. Or with Locale. Or Profile.
There are many facilities to help with this type of thing.

> 
> Are you stating that 4.9 could/would make these process more automated 
> and if so, is it worth be attempting to pull from the CVS to snag that 
> portion and attempt to integrate it into 4.8.5 now?

I never will suggest that. It would be more reliable to use 4.9 at
this point.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike@perusion.com>

Nature, to be commanded, must be obeyed. -- Francis Bacon