I'm using Hybris 1905, in my project I have 3 indexes, each fo them with its own indexed type and product catalog, one of them is old (has existed since the beginning of the project) and the other 2 are kind of new, we already created an AsCategoryAwareSearchProfile and AsSearchProfileActivationSet for each of the indexes, when accessing Adaptive Search FACETS overriding is working well, but BOOSTS is not working well for the 2 new indexes (it works perfectly for old index), so not sure what config I may be missing for these...
This is what it looks like when promoting and item using old index(as expected):
And this si what it looks like when promoting and item using one of new indexes(score is apparently not being updated):
The issue was the main SolrSort (usually called "relevance") needed to set the "Use Boost" flag to true (it was false)
Related
I’ve created new Segmented Keys in ACUMATICA for use in a specific module. I would like to assign the Dimension name dynamically but I noticed it works only with hard code or name like [PXDimension(“VENDOR”)]
Also, I have some limitation to create an IF Conditional inside the customized field… it does not recognize the IF clause (see the image).
I would appreciate any suggestion how to solve this issue.
I haven't seen how your original attempt at PXDimension looked, but I'm going to take a guess and assume you tried to reference a new custom field contained in a setup table, something like:
[PXDimension(typeof(XXMySetup.usrMyCustomField))]
If that's indeed what you tried to do, one very important thing to do is to ensure that you have a view for your table in your graph, otherwise the attribute will not find the table and record in your cache. For instance:
public PXSetup<XXMySetup> XXMySetup;
Without this view declared in the graph, the dimension attribute will not work as expected. It would be nice if a clear exception was thrown in this case - I made the same mistake recently and it would have been helpful.
I have a database called "development-records" that has a MapReduce view with a "dbcopy" declaration that creates a view in a new database called "development-chained".
When we make an update the view in "development-records", we do the usual steps of:
1. Create a duplicate copy of the design document that we want to change, for example by adding _OLD to its name: _design/fetch_OLD.
2. Put the new or 'incoming' design document into the database, using a name with the suffix _NEW: _design/fetch_NEW.
3. Query the fetch_NEW view, to ensure that it starts to build.
4. Poll the _active_tasks endpoint and wait until the index has finished building.
5. Put a duplicate copy of the new design document into _design/fetch.
6. Delete Design Document _design/fetch_NEW.
7. Delete Design Document _design/fetch_OLD.
The problem is that the documents specified in the dbcopy database "development-chained" don't seem to be updated -- all the old records stay. Is there a way to trigger the dbcopy database to perform the MapReduce again?
Unfortunately, according to the official Cloudant documentation, "The dbcopy feature can cause problems under some circumstances." Use of this feature is strongly discouraged, and has otherwise been removed from the documentation. I hope knowing that helps a little. The new documentation is hard to find.
It seems that facets doesn't work properly with multi language properties.
I did a simple test in Alfresco 5.0.a and 5.0.b on clean installation:
Created a text document in site.
Put description in English.
Changed browser language to French.
Added French version of the description.
Searched for the file name.
Found only one document which was just created.
The problem is that in Description facet on the left panel I have two descriptions - one English and one French.
Both points to the same file, but logically there should be only one description (depends on the browser's language).
Did anybody faced this problem? It seems like a bug.
Hi I'm not sure if it's a bug, but technically it looks like it should be.
Multilingual fields contains multiple text definitions of the same field. Solr indexes the field and sees there are 2 values (even though for the same field) so he creates a facet out of them.
Sure it's possible in the UI to filter out, Alfresco probably will need to do it (raise a JIRA so they can take a look). But in case of technical faceting/filtering it works like it should.
I raised an issue ALF-21249
And also found a workaround, which is a bit dirty, but works well.
Let's say you have a property with name ccm:property which has type d:mltext and you want to have facet for this property in English and French.
Define an aspect with two d:text properties: ccm:propertyEn and ccm:propertyFr
Apply this aspect to the type.
When you set the ccm:property set also ccm:propertyEn and ccm:propertyFrproperties
Modify variable facets in faceted-search.get.js so that depends on the user's language one or another facet are shown:
if (locale.substring(0, 2)== "fr")
facetQName = "{http://www.ccm.com/model/ccm/1.0}propertyFr.__.u";
else
facetQName = "{http://www.ccm.com/model/ccm/1.0}propertyEn.__.u";
facets.unshift(
{
id: "FCTSRCH_FACET_DOCUMENT_TYPE",
name: "alfresco/search/FacetFilters",
config: {
label: msg.get("faceted-search.facet-menu.facet.docType"),
facetQName: facetQName,
sortBy: "ALPHABETICALLY",
hitThreshold: 1,
minFilterValueLength: 5,
maxFilters: 10,
useHash: false
}
});
Done! :)
I have a Content Part in Orchard, to which I added a Taxonomy Field and set it to allow multiple terms. When I save a content item, it looks like the terms are re-ordered in alphabetical order. But I would like to preserve the order in which they were authored in the field.
E.g. here is what I author in my Taxonomy field:
Contributors: [Sebastien Ros] [Bertrand Le Roy]
And here is what it turns into after saving:
Contributors: [Bertrand Le Roy] [Sebastien Ros]
Is there a way to prevent terms re-ordering? If this is by design, does anyone familiar with implementation know if this can be patched easily? Would it make sense to create a pull-request and contribute a patch to Orchard? I mean, would it be useful for other users, so that the fix has a chance to be included in core. (Otherwise, I would have to maintain a modified version of Orchard and have problems upgrading to new versions, which is undesirable of course).
Thanks!
You should never count on the order in which the records are stored in the database. It is way too brittle, and has never been designed for this. If you need to have control over the order of terms, and have different orders depending on context, you need to use something else. The latest source code version of Vandelay.Industries has a projection filter that lets you drag and drop items in the order you want, for that specific projection.
If you go to the taxonomy section and look for the term itself, you will see a property call Weight which says..: 'If specified, it will be used to sort terms at the same level'.
That should do it.
We have the sharepoint 2010 environment with Document ID's enabled.
Given (part of) a Doc ID, we want to programmatically retrieve the document(s) matching that ID. The problem seems to be that this column is rather special, in that it might need special handling.
Using an SPSiteDataQuery, fetching the _dlc_DocId field as part of the viewfields works fine. However, including it as part of the where query never results in any documents being fetched.
Using the Search API has gotten us nowhere at all.
Has anyone pulled this off, or any suggestions on how to tackle this problem?
[Update] Turns out we were fooled by subtle errors in the XML and bad debugging misinterpretations. This stuff just works fine.
I don't normally contribute to these sorts of things because cleverer people than I always get there before me, but as this is an old one with no proper answer I think I'll add my thoughts for those who find this page.
I was struggling with this but after a little digging around and learning a bit of Caml I got this working.
I am using the SharePoint Client Object Model against SharePoint 2010 and Office365 beta.
Start off your query by looking at the all list items query:
Microsoft.SharePoint.Client.CamlQuery.CreateAllItemsQuery().ViewXml
"<View Scope=\"RecursiveAll\">\r\n <Query>\r\n </Query>\r\n</View>"
Stick a where child inside the query
Then add in
<Eq><FieldRef Name="_dlc_DocId" /><Value Type="Text">MDXC2KE55ASN-3-80</Value></Eq>
replacing MDXC2KE55ASN-3-80 with the doc ID you are looking for inside the where.
Also don't forget you might want to make use of these too:
<ViewFields><FieldRef Name="_dlc_DocId" /></ViewFields>
<RowLimit>1</RowLimit>
Then use List.GetItems() method to bring back the ListItemCollection.
Just in case nobody comes with a slick solutions from the depths of the Sharepoint infrastructure:
What would Google Do?
Slice is, Dice it and dump it in a reverse index.
Solr and Lucene offer supreme tools for this. The idea is to cut the DocId's in small pieces and add the location of the document to the bucket for that piece.
Say We have "A real nice document" with Id ABCD123. You would add it to the buckets
ABCD, BCD1, CD12, D123
When searching for a partial ID (+ other data like dates, types, ...) you (well the search engine) creates the union of the buckets + applies additonal constraints.
To make this happen you need to write a spider for the sharepoint server and a routine which makes a record of data elements to be indexed.
Put a nice REST interface in frnt of it (actually SOLR already has that), integrate it in the main sharepoint server, and nobody needs to know there is something else running behind it.
These products can also incrementally update the indexes, so they can be kept up to date.
you could use the following to get the Document ID.
SPFile file = MethodToUploadFileToServer(web, filepath);
SPListItem item = file.Item;
string DocID = item.Properties["_dlc_DocId"].ToString();