magento exclude bundled items from search results - search

Currently, when one searches for an item, the quick search also brings up any bundles that contain items that fit the search criteria. How would I stop this?
A solution that filters out all bundled items from search results all together would be fine too.
UPDATE
I don't want the items to show in either the catalogue or search, but am using them as upsell items. This seems to leave two options:
I could amend the search results controller to omit bundled items (the method I was asking about), or
I could change the Upsell.php script to include "Don't show individually" items.
The second is perhaps easier? Currently the filter applied is:
Mage::getSingleton('catalog/product_visibility')->addVisibleInSearchFilterToCollection($this->_itemCollection);
How would I change this so it shows don't show individually items?
Apologies for the incomplete initial question.
Second Update:
Ok, I've added
->setVisibility(null)
and it already has
->addStoreFilter()
But there is no change.
Essentially, if I don't have either of:
Mage::getSingleton('catalog/product_visibility')->addVisibleInCatalogFilterToCollection($this->_itemCollection);
Mage::getSingleton('catalog/product_visibility')->addVisibleInSearchFilterToCollection($this->_itemCollection);
Then I get the following error:
SELECT 1 AS status, e.entity_id, e.type_id, e.attribute_set_id, price_index.price, price_index.tax_class_id, price_index.final_price, IF(price_index.tier_price IS NOT NULL, LEAST(price_index.min_price, price_index.tier_price), price_index.min_price) AS minimal_price, price_index.min_price, price_index.max_price, price_index.tier_price, e.name, e.short_description, e.sku, e.price, e.special_price, e.special_from_date, e.special_to_date, e.manufacturer, e.manufacturer_value, e.small_image, e.thumbnail, e.news_from_date, e.news_to_date, e.tax_class_id, e.url_key, e.required_options, e.image_label, e.small_image_label, e.thumbnail_label, e.price_type, e.weight_type, e.price_view, e.shipment_type, e.links_purchased_separately, e.links_exist, e.is_imported, e.rc_manufacturer, e.rc_manufacturer_value, e.rc_vehicle, e.rc_vehicle_value, e.rc_assembly_type, e.rc_assembly_type_value, e.surface_type, e.surface_type_value, e.rc_drive, e.rc_drive_value, e.rc_scale, e.rc_scale_value, e.rc_motor_type, e.rc_motor_type_value, e.rc_engine_start_type, e.rc_engine_start_type_value, e.rc_engine_size, e.rc_engine_size_value, e.rc_form_factor, e.rc_form_factor_value, e.rc_frequency, e.rc_frequency_value, e.rc_gear_material, e.rc_gear_material_value, e.rc_operation, e.rc_operation_value, e.rc_torque_6v, e.rc_torque_6v_value, e.rc_speed_6v, e.rc_speed_6v_value, e.rc_bearing_type, e.rc_bearing_type_value, e.rc_waterproofing, e.rc_waterproofing_value, e.rc_battery_application, e.rc_battery_application_value, e.rc_input_supply, e.rc_input_supply_value, e.rc_power_output_amps, e.rc_power_output_amps_value, e.rc_power_output_watts, e.rc_power_output_watts_value, e.rc_lead_connector_type, e.rc_lead_connector_type_value, e.rc_gear_pitch, e.rc_gear_pitch_value, e.rc_nitro_content, e.rc_nitro_content_value, e.rc_exhaust_type, e.rc_exhaust_type_value, e.rc_engine_starter_type, e.rc_engine_starter_type_value, e.rc_head_fitting, e.rc_head_fitting_value, e.rc_temperature_rating, e.rc_temperature_rating_value, e.rc_oil_type, e.rc_oil_type_value, e.rc_container_size, e.rc_container_size_value, e.rc_class, e.rc_class_value, e.rc_paint_application, e.rc_paint_application_value, e.rc_size, e.rc_size_value, e.rc_colour, e.rc_colour_value, e.rc_pack_contents, e.rc_pack_contents_value, e.rc_spare_part_type, e.rc_spare_part_type_value, e.rc_oil_weight, e.rc_oil_weight_value, e.rc_glue_type, e.rc_glue_type_value, e.rc_usage, e.rc_usage_value, e.rc_tool_type, e.rc_tool_type_value, e.rc_engine_spare_type, e.rc_engine_spare_type_value, e.rc_tune_up_type, e.rc_tune_up_type_value, e.rc_bearing_pack_type, e.rc_bearing_pack_type_value, e.rc_driver_type, e.rc_driver_type_value, e.rc_nut_type, e.rc_nut_type_value, e.rc_plane_type, e.rc_plane_type_value, e.rc_boat_type, e.rc_boat_type_value, e.pre_order, e.pre_order_value, e.msrp_enabled, e.msrp_display_actual_price_type, e.msrp, links.link_id, link_attribute_position_int.value AS position FROM catalog_product_flat_1 AS e
INNER JOIN catalog_product_index_price AS price_index ON price_index.entity_id = e.entity_id AND price_index.website_id = '1' AND price_index.customer_group_id = 0
INNER JOIN catalog_product_link AS links ON links.linked_product_id = e.entity_id AND links.link_type_id = 4
LEFT JOIN catalog_product_link_attribute_int AS link_attribute_position_int ON link_attribute_position_int.link_id = links
I've also tried the following, but get the error:
Mage::getSingleton('catalog/product_status')->addSaleableFilterToCollection($this->_itemCollection);
Mage::getSingleton('catalog/product_status')->addVisibleFilterToCollection($this->_itemCollection);
Thanks for the help.

Based on your updated question:
If you are not using Enterprise Edition TargetRule or some other module which automates upsells (i.e. the upsells are defined explicitly by the admin), then likely the simplest approach is that which you've specified - rewrite the Upsell block to not add the visibility filter. As a guess, to be optimal you may want to call setVisibility(null) and addStoreFilter() on the collection to trigger normal limiting behavior.
EDIT: Original answer below
Admin > Catalog > Manage Products grid
Choose "Bundle Product" from the filters area at the top, click "Search"
Click "Select All"
Select "Update Attributes" from the mass action block's "Action" dropdown, click "Submit"
Change the "Visibility" attribute to "Catalog"

I solved it by modifying the custom module so that I didn't need to worry about this. It may be of some use as it involved using:
$collection->addAttributeToFilter('type_id', array('neq' => 'bundle'));
Which just excludes all bundle items from a collection.

Related

NetSuite Search formula for items that have no open transactions

I am trying to create a formula to obtain a list of items that have no open transactions.
I cant just filter out by status as this filters out transactions that are open, as opposed to showing me only items with nothing open.
So basically if an item has anything open then i dont want it on the search. I do need it on the search if it has all closed or it has no transactions at all.
Hoping someone can help put me in the right direction.
I am a little bit stuck at where to start with the formulas and tried a case formula.
You can use item saved search adding under criteria as "Transaction Fields-status-anyOf-select all closed/rejected/declined statuses" not in filter reason of saved search.
Thanks.
To get the value of non transaction items as well, You need to check the check box use expression under criteria in standard subtab use parens() with OR expression.
And add one more condition as "Transaction Fields-Internal Id-anyOf-none with
"Transaction Fields-status-anyOf-select all closed/rejected/declined statuses".
Add both condition with OR logic.
It will work for both items condition if it has transaction status with closed or with none of transaction internal ids.
Thanks.
I think this is possible in a saved search, and requires a change in the way the filtering is done. Rather than filtering on the "Filters", using grouping and summary calculations to determine if an item qualifies, basically :
Create the item saved search as you would normally, but don't include a "Standard" filter for the openness of the transaction.
In the results, group by item name (or internalid), and another fields you want to include in the top-level results.
In the Criteria - Summary list, add a Formula (Number) condition :
Summary Type= Sum (Count won't work here)
Formula = case when {transaction.status} = 'Open' then 1 else 0 end
Equal to 0
Whether this is more or less elegant than bknight's answer is debatable.
I don't think this is the sort of thing you can do with a single saved search.
It would be fairly easy to do with SuiteQL though.
The script below runs in the console and finds items that are not on any Pending Billing Sales Orders. It's adapted from a script with a different purpose but illustrates the concept.
You can get a list of the status values to use by creating a saved search that finds all the transactions with open statuses you want to exclude , take note of that saved search's id and running the second script in the console
require(['N/query'], query => {
const sqlStr = `
select item.id, itemid, count(po.tranid) as po, count(bill.tranId) as bill, max(bill.tranDate) as lastBilled, count(sale.tranId) as sales, count(tran.tranId) as trans
from item
left outer join transactionLine as line
on line.item = item.id
left outer join transaction as tran on line.transaction = tran.id
left outer join transaction as po on line.transaction = po.id and po.type = 'PurchOrd'
left outer join transaction as bill on line.transaction = bill.id and bill.type = 'VendBill'
left outer join transaction as sale on line.transaction = sale.id and sale.type in ('CustInvc', 'CashSale')
where item.id not in (select otl.item from transactionLine otl, transaction ot where
otl.transaction = ot.id and ot.status in ('SalesOrd:F'))
group by item.id, item.itemid
`;
console.log(sqlStr);
console.log(query.runSuiteQL({
query: sqlStr
}).asMappedResults().map((r, idx)=>{
if(!idx) console.log(JSON.stringify(r));
return `${r.id}\t${r.itemid}\t${r.po}\t${r.bill}\t${r.lastBilled}\t${r.sales}\t${r.trans}`;
}).join('\n'));
});
require(['N/search'], search=>{
const filters = search.load({id:304}).filters;
console.log(JSON.stringify(filters.find(f=>f.name == 'status'), null, ' '));
});
In terms of doing something with this you could run this in a saved search and email someone the results, show the results in a workbook in SuiteAnalytics or build a portlet to display the results - for this last Tim Dietrich has a nice write up on portlets and SuiteQL

Populating custom table on Shipment release

I have created a custom table and made it available on the Customers screen called 'Serial Tracking'. The purpose of this screen is to track serialised items that each customer is in possession of (regardless of who the item was purchased from).
I would like a record automatically added to the table on shipment release. I have attempted to customise the Release method of SoShipmentEntry but am having trouble getting all the required data together as well as the best way to structure the code.
The custom table DAC is
AUSerialTrack
Not necessarily the answer to your question but to long for a comment.
As an alternative, what if you set your Serials tab view to the Ship Line Split table without dealing with a custom table. You could get the information you needed with something like this: (need to convert to your BQL view for your serials tab)
SELECT [ship].[CustomerID],
[ship].[ShipmentNbr],
[split].[InventoryID],
[split].[LotSerialNbr]
FROM [dbo].[SOShipLineSplit] split
INNER JOIN [dbo].[SOShipLine] line
ON [line].[CompanyID] = [split].[CompanyID]
AND [line].[ShipmentNbr] = [split].[ShipmentNbr]
AND [line].[LineNbr] = [split].[LineNbr]
INNER JOIN [dbo].[SOShipment] ship
ON [ship].[CompanyID] = [split].[CompanyID]
AND [ship].[ShipmentNbr] = [split].[ShipmentNbr]
INNER JOIN [dbo].[InventoryItem] i
ON [i].[CompanyID] = [split].[CompanyID]
AND [i].[InventoryID] = [split].[InventoryID]
INNER JOIN [dbo].[INLotSerClass] c
ON [c].[CompanyID] = [i].[CompanyID]
AND [c].[LotSerClassID] = [i].[LotSerClassID]
WHERE [c].[LotSerTrack] = 'S'
AND [ship].[Confirmed] = 1;
Then when the user goes to the tab its always the current results. No custom code to fill in a custom table so easier for upgrades/customization maintenance.

find_field with Poltergeist/Capybara

I have a problem with Poltergeist. I can’t get the driver to locate a field on a page. What I want to do is to execute some js to make sure that the input field is empty before I start adding new text. I have a field with a label os "Skill list" and id of "user_skill_list". In order to make the step more generic I want to find the field by the label name and then get the id.
And(/^I delete the content of "([^"]*)"$/) do |label|
field_id = page.find_field(label).native.attributes['id'].value
page.execute_script("$('#{field_id}').val('');")
end
Here's the error message:
#javascript
Scenario: Update user by removing # features/godmin/skills.feature:36
Given "Thomas" skills are "rspec, testing" # features/step_definitions/godmin_steps.rb:63
And I click on "Edit" for "Thomas" # features/step_definitions/godmin_steps.rb:43
And I delete the content of "Skill list" # features/step_definitions/godmin_steps.rb:69
Unable to find field "Skill list" (Capybara::ElementNotFound)
./features/step_definitions/godmin_steps.rb:70:in `/^I delete the content of "([^"]*)"$/'
features/godmin/skills.feature:39:in `And I delete the content of "Skill list"'
```
My cucumber set up is pretty basic.
# features/support/env.rb
...
require 'capybara/poltergeist'
Capybara.javascript_driver = :poltergeist
Capybara.default_max_wait_time = 5
...
Thank you. Please let me know if I should clarify my question.
Assuming your html is something like
<label for="user_skill_list">Skill list</label>
<input id="user_skill_list"/>
Then
page.find_field('Skill list').set('')
should find the field and clear it. If it's not finding the element there are a couple of possibilities.
The element isn't visible on the page
There is CSS being applied that is changing the case of "Skill list"
There are typos in your html so the label isn't actually associated with the field. You can test this by just doing page.find_field('user_skill_list').set('') so the label isn't involved
Note: you can get the id by just doing page.find_field('Skill list')[:id] rather than having to resort to .native.xxxx - although it's not really needed for this use case

Customize the search portlet in Plone for specific content types

I'm using the search portlet in certain areas of my website, but I'd like to restrict the results to only search for a specific content type: for example only search the news items, or only show Faculty Staff Directory profiles.
I know you can do this after you get to the ##search form through that "filter" list, but is there a way to start with the filter on, so that the "Live Search" results only show the relevant results (i.e. only news items or only profiles).
I suspect you know it already, but just to be sure: You can globally define which types should be allowed to show up in searchresults in the navigations-settings of the controlpanel, and then export and include the relevant parts to your product's GS-profile-propertiestool.xml.
However, if you would like to have some types excluded only in certain sections, you can customize Products.CMFPlone/skins/plone_scripts/livesearch_reply, which already filters the types, to only show "friendly_types" around line 38 (version 4.3.1) and add a condition like this:
Edit:
I removed the solution to check for the absolute_url of the context, because the context is actually the livesearch_reply in this case, not the current section-location. Instead the statement checks now, if the referer is our section:
REQUEST = context.REQUEST
current_location = REQUEST['HTTP_REFERER']
location_to_filter = '/fullpath/relative/to/siteroot/sectionId'
url_to_filter = str(portal_url) + location_to_filter
types_to_filter = ['Event', 'News Item']
if current_location.find(url_to_filter) != -1 or current_location.endswith(url_to_filter):
friendly_types = types_to_filter
else:
friendly_types = ploneUtils.getUserFriendlyTypes()
Yet, this leaves the case open, if the user hits the Return- or Enter-key or the 'Advanced search...'-link, landing on a different result-page than the liveresults have.
Update:
An opportunity to apply the filtering to the ##search-template can be to register a Javascript with the following content:
(function($) {
$(document).ready(function() {
// Let's see, if we are coming from our special section:
if (document.referrer.indexOf('/fullpath/relative/to/siteroot/sectionId') != -1) {
// Yes, we have the button to toggle portal_type-filter:
if ($('#pt_toggle').length>0) {
// If it's checked we uncheck it:
if ($('#pt_toggle').is(':checked')) {
$('#pt_toggle').click();
}
// If for any reason it's not checked, we check and uncheck it,
// which results in NO types to filter, for now:
else {
$('#pt_toggle').click();
$('#pt_toggle').click();
}
// Then we check types we want to filter:
$("input[value='Event']").click();
$("input[value='News Item']").click();
}
}
})
})(jQuery);
Also, the different user-actions result in different, inconsistent behaviours:
Livesearch accepts terms which are not sharp, whereas the ##search-view only accepts sharp terms or requires the user to know, that you can append an asterix for unsharp results.
When hitting the Enter/Return-key in the livesearch-input, the searchterm will be transmitted to the landing-page's (##search) input-element, whilst when clicking on 'Advanced search...' the searchterm gets lost.
Update:
To overcome the sharp results, you can add this to the JS right after the if-statement:
// Get search-term and add an asterix for blurry results:
var searchterm = decodeURI(window.location.search.replace(new RegExp("^(?:.*[&\\?]" + encodeURI('SearchableText').replace(/[\.\+\*]/g, "\\$&") + "(?:\\=([^&]*))?)?.*$", "i"), "$1")) + '*';
// Insert new searchterm in input-text-field:
$('input[name=SearchableText]').val(searchterm);
Update2:
In this related quest, Eric Brehault provides a better solution for passing the asterix during submit: Customize Plone search
Of course you can also customize the target of advanced-search-link in livesearch_reply, respectively in the JS for ##search, yet this link is rather superfluous UI-wise, imho.
Also, if you're still with Archetypes and have more use-cases for pre-filtered searchresults depending on the context, I can recommend to have a look at collective.formcriteria, which allows to define search-criteria via the UI. I love it for it's generic and straightforward plone-ish approach: catalogued indizi and collections. In contradiction to eea.facetednavigation it doesn't break accessibility and can be enhanced progressively with some live-search-js-magic with a little bit of effort, too. Kudos to Ross Patterson here! Simply turn a collection (old-style) into a searchform by changing it's view and it can be displayed as a collection-portlet, as well. And you can decide which criteria the user should be able to change or not (f.e. you hide the type-filter and offer a textsearch-input).
Watch how the query string changes when you use the filter mechanism on the ##search page. You're simply adding/subtracting catalog query criteria.
You may any of those queries in hidden fields in a search form. For example:
<form ...>
....
<input type="hidden" name="portal_type" value="Document" />
</form>
The form on the query string when you use filter is complicated a bit by its record mechanism, which allows for some min/max queries. Simple filters are much easier.

Cascading list boxes, with multi-select

I wound up modifying the source from a publically posted POC: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx, which is a custom field definition for cascading drop downs. The modifications were to allow parent-child list boxes where a user can multiselect for filtering and selecting the values to be written back to a SharePoint list. I got the parent-child cascading behavior working, but the save operation only takes the first value that is selected from the list box. I changed the base type for the custom field control from "SPFieldText" to "SPMultiLineText", along with changing the FLD_TYPES field definition values from:
Text to Note and this did not work. So, I changed the field control base type to "SPFieldMultiChoice" and the FLD_TYPES to "MultiChoice" and still get the same result, which is only the first value that's selected, writing to the SharePoint list.
Does anyone have any idea how to get a custom field with multiple selections to write those multiple selections to a SharePoint list?
Thanks for taking the time to read through my post.
Cheers,
~Peter
I was able to accomplish this by inheriting from SPFieldLookup and overriding its internal handling of AllowMultipleValues:
In your FLDTYPES_*.xml set <ParentType>LookupMulti</ParentType>
In your extension of SPFieldLookup, be sure to override AllowMultipleValues (always true), FieldValueType (probably typeof(SPFieldLookupValueCollection)) and FieldRenderingControl. I also set base.LookupField = "LinkTitleNoMenu", though in retrospect I'm not sure why. :)
In your field editor control's OnSaveChange(), set the field's Mult value to true.
To set Mult, you can either string manipulation on field.SchemaXml:
string s = field.SchemaXml;
if (s.IndexOf(" Mult=", StringComparison.OrdinalIgnoreCase) < 0)
field.SchemaXml = s.Insert(s.IndexOf("/>", StringComparison.Ordinal), " Mult=\"TRUE\" ");
Or use reflection:
var type = field.GetType();
var mi = type.GetMethod("SetFieldBoolValue", BindingFlags.Instance | BindingFlags.NonPublic);
mi.Invoke(field, new object[] { "Mult", true });
It's been a while, so I might be forgetting something, but that should be most of it.

Resources