We added the department number from AD to sharepoint. This property is multi valued in AD, and its multivalue in sharepoint.
My user profile screenshot:
http://screencast.com/t/e9xaZMyJJ2
Then in the CSWP, I want to filter by this value, please check here:
http://screencast.com/t/rlP95vrYRB3E
If I check the TEST, its using a GUID instead of the 613 code
http://screencast.com/t/ASltLUsIP
I am totally clueless.!! any idea?
Mapped property screenshot here:
http://screencast.com/t/gLXs2ZIR
In your user profile the department number is stored as a 'term' using a managed metadata field.
It's important to know that a 'term' can be translated or you can even define synonyms.
When using managed metadata in search, search will use the id (=a guid) of the term instead of the actual text ('613').
Since it ignores the text (and uses the id of the term), this makes it possible for search to find your term in any language or synonyms.
In your case translation of '613' is not really applicable but imagine that your department was a text instead of a number.
When searching on the term 'HR', search could return all the items with 'HR' but also the ones with 'personeelsdienst' (HR in Dutch).
Related
If I may have missed this in some other area of SO please redirect me but I don't think this is a duped question.
I am using Azure Search with an index field called Title which is searchable and filterable using a Standard Lucerne Analyzer.
When using the built-in explorer, if I want to return all Job Titles that are explicitly named Full Stack Developer I can achieve it this way:
$filter=Title eq 'Full Stack Developer'&$count=true
But if I want to retrieve all the Job Titles using a wildcard to return all records having Full Stack in the name this way:
$filter=Title eq 'Full Stack*'&$count=true
The first 20 or so records returned are spot on, but after that point I get a mix of records that have absolutely nothing in common with the Title I specified in the query. My initial assumption was that perhaps Azure was including my specified Title performing an inclusive keyword search on the text as well.
Though I found a few instances where that hypothesis seemed to prove out, so many more of the records returned invalidated that altogether.
Maybe I don't understand fully the mechanics under the hood of Azure Search and so though my query appears to be valid; my expectation of the result is way off.
So how should my query look to perform a wildcard resulting to guarantee the words specified in the search to be included in the Titles returned, if this should be possible? And what would be the correct syntax to condition the return to accommodate for OR operators to be inclusive?
Azure Cognitive Search allows you to perform wildcard searches limited to specific fields only. To do so, you will need to specify the name of the fields in which you want to perform the search in searchFields parameter.
Your search URL in this case would be something like:
https://accountname.search.windows.net/indexes/indexname/docs?api-version=2020-06-30&searchFields=Title&search=Full Stack*
From the link here:
I'm trying to implement Azure Search on Kentico 12. Following the article below.
https://docs.kentico.com/k12/configuring-kentico/setting-up-search-on-your-website/using-azure-search/integrating-azure-search-into-pages
However, I have multiple indexes defined on the smart search not just a single index code name that I can hard code and also cannot aford to hard code index fields. Is there any tutorial out there that I can follow?
It sounds as if you're referring to building an Azure Search web part, is this correct. If so, make a property in your web part which allows you to select the code name from a list in the database. Secondly, regarding field names, you should be using generic field names like DocumentName, NodeAliaspath, etc. Although if you have very specific search results that need to be displayed, simply put in a switch statement to get the field names based on a class name.
According to the help pop up:
ID
This field's value represents the script ID, used to identify this
record for scripting purposes. It is a text field.
Internal ID
This field's value is a read-only system-generated unique identifier.
It is an integer field.
Both fields seem to uniquely identity a record type.
One is a string, one a integer.
The string ID is used for searches and
loading of records, but I've also seen Internal ID used when
referring to a record type from a lists point of view.
Can anyone provide the reasoning behind having two identifiers and when to use one versus the other when scripting?
The major difference is that you (as the creator of a custom record or script) are in complete control of the text ID. You can establish patterns and best practices for defining these IDs, and it will make it very easy for developers to identify record types just by looking at the string ID. You have no control over the numeric ID. When looking at code, it is much easier for me to determine what records I am referring to if it looks like:
nlapiSearchRecord('customrecord_product', null, filters, columns);
nlapiResolveURL('SUITELET', 'customscript_sl_orderservice', 'customdeploy_sl_orderservice')
as opposed to looking at:
nlapiSearchRecord(118, null, filters, columns);
nlapiResolveURL('SUITELET', 13, 1)
I'm not even sure the second nlapiSearchRecord actually works, but I know that nlapiResolveURL can be written that way.
That said, if you simply let NetSuite generate the text ID, you'll end up with generic IDs like customrecord1, which I find no more useful than the numeric ID. It is a good practice to explicitly specify your own IDs.
Furthermore, the numeric ID can vary between environments (e.g. Sandbox could be different than Production, until a subsequent refresh occurs). If you are following good migration practices, then the text ID should never vary between environments, so your code would not have to make any kind of decision on which ID to use based on environment.
Rarely have I found myself referencing any record, whether native or custom, by its numeric ID; scripts are always using the text ID to reference a record type.
I'm trying to dynamically construct URLs in an ASP.NET MVC website that point back to a SharePoint list view with a Key Filter enabled for a managed metadata field (which uses a TermSet).
If I configure a navigation hierarchy for the managed metadata field, I see the following in the URL:
TreeField=MyCategory&TreeValue=0C37852B-34D0-418E-91C6-2AC25AF4BE5B
However, if configure the managed metdata field as a KeyFilter, I see the following in the URL:
#ServerFilter=FilterField1=MyCategory-FilterValue1=247-FilterLookupId1=1-FilterOp1=In
Where does the FilterValue1 value of 247 come from? It is not the database id of the MyCategory term. It is also not present anywhere on the Term object when loading the taxonomy through the SharePoint API. Is there a way to construct the query string to use the guid for the term (or better yet, the label, which I know will be unique).
The value comes from the taxonomy hidden list. Use the following method GetWssIdSoftTerm to get the int value the above urls are using to filter the data.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.taxonomy.taxonomyfield.getwssidsofterm.aspx
Name of the column in document library is :
Column name => Keywords (Sub-Processes, Methodology, Servicing Model, etc)
Column Type=> Multiple lines of text
We are using the above column name in the caml query as below
query.Query = "<Where><Eq><FieldRef Name='Keywords(Sub-Processes,Methodology,Servicing Model, etc)'/><Value Type='Text'>Merchant Services,Merchant Set Up</Value></Eq></Where>";
but when we run the code we get the exception:
Microsoft.SharePoint.SPException: One or more field types are not
installed properly. Go to the list settings page to delete these
fields.
Is this exception because of special characters used in the column name if yes then how can I correct it.
We can't change the column name because it is requirement.
Internal names and display names are quite different from each other. They can be the same in some cases but not all. There is generally an escape sequence in between two words with a space.
It is often a good practice to retrieve the internal name at runtime rather than hardcoding it.
Here's how to do it:
var internalName=list.Fields.GetFieldByInternalName(column.ColumnName).Title;
I can tell you for sure (given the special characters) that that's not the internal name of the field. It might be the display name, but it's not the internal name.
The error is because there is no field with an internal name of what you have provided.
Personally, when I want to find the internal name of a field I go to the list settings for the list and edit the column. When doing so there will be a query parameter with 'field=' followed by the internal name. There are other places that it can be found, and other sharepoint tools (SharePoint Manager was mentioned by another poster) that can be used to get such information.
I used "Keywords_x0020_x002f_x0020_Folksnomy" and it worked for me.
I fetched all the columns of the Document library and bind it to the GridView,in GridView I found this name.
Display Column name => Keywords (Sub-Processes, Methodology, Servicing Model, etc)
Wrong one is =>
Keywords_x0020_(Sub-Processes,_x0020_Methodology,_x0020_Servicing_x0020_Model,_x0020_etc)
Newly found correct name is => Keywords_x0020_x002f_x0020_Folksnomy