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
Related
I want to build a sharepoint online search result source that includes only some site collections and subsites. I have over 5000 Site collections, so I can't use named URLs/site ids in the result source - not maintainable. Instead I hope to add an indexed property to a site's property bag after site is provisioned then map a managed property to it, and use it in a resultsource to filter search results to match only content found in sites that have that property value. The Phil Harding's article describes the approach: https://platinumdogs.me/2015/02/06/set-a-propertybag-property-as-indexed-queryable-via-search-using-csom-powershell/ and Mike Morawski adds some code for the indexed property encoding - http://www.migee.com/2015/09/14/allowing-property-bag-values-to-be-searched-via-sharepoint-search/ I used bits of both to implement this approach.
Approach:
Add Key = 'SiteType', Value = 'MySiteType' to Web All Properties
Add Indexed Property 'SiteType' with 'MySiteType' Value to web IndexedProperties (vti_indexedpropertykeys). Key encoded to base64
Add Managed Property 'propSiteType' mapped to 'SiteType' Crawled property in Search Schema manually.
I've done 1 and 2 via Powershell+CSOM, and verify site property added and is crawled. Managed Property is there, but It is not available in ResultSource builder dialog, and any searches such as {searchterms} propSiteType:MySiteType or (contentclass:STS_Web OR contentclass:STS_Site) propSiteType:MySiteType do not return results.
Ideas or alternative approaches? Thanks in advance
My only thought is an indexing delay. I have seen O365 take days to index new content, and that's even when manually requesting a crawl. If that was the issue, it's probably resolved by now. Are you seeing relevant search results?
https://www.sharepointnutsandbolts.com/2013/10/waiting-for-search-crawl-in-office-365.html
I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.
Have mapped properties for custom fields used in multiple site collections.
The property is also used to display additional information on the search results page if it contains information.
The search results work fine as content from each site collection is returned, but the managed property only contains data for content found on one particular site collection.
When configuring the managed property, there is only one option available to select the custom field I wish to map.
A full crawl has completed since configuring the managed property. The content from each site collection is being indexed, but the managed properties are only populated with data for content on one site collection.
Are the fields available to select when configuring a managed property from all site collections, or do I need to change a setting somewhere to tell it to look for custom fields in an alternate site collection?
Thanks in advance.
I've done this before and it is possible and indeed straightforward, you do not need to set any special settings. Just make sure that the internal names of the fields are the same (or all names are mapped to the managed property) and all lists/sites are set to be included in search results
I have pages in a pages library on a publishing site which have a managed metadata (taxonomy) field in their content type. I want my custom search webpart to read the taxonomy set on its parent page (I can do this fine) and then query against a specific scope using only the selected tags of the parent page as the filter (no keyword necessary).
I have tried to set FixedQuery = âowstaxIdMetadataAllTagsInfo=#0[TERM GUID]â of my CoreResultWebPart with no success... I actually gave up after I was getting 0 results and am now trying to just perform a FullTextSqlQuery.
Unfortunately it seems that even though pages with the managed metadata field are successfully being indexed, the managed property owstaxIdMetadataAllTagsInfo has no data in the results! I went ahead and made the property searchable/queryable and the property value is null.
Can you anyone confirm that I should be getting values from that managed property when there is indeed a managed metadata field on the page that is populated with data?
Note: I have tried to make my own managed property based on the managed metadata field in my site's content type -- same results.
I don't think - owstaxIdMetadataAllTagsInfo returns anything. I tried adding it to my result web part's Diaplay properties > fetched properties and got a property not recognized...related error.
So I created a separate metadata property for 'enterprise keywords' i.e. 'TaxKeyword. You need to ensure that you check the checkbox - 'Reduce storage requirements for text properties by using a hash for comparison' otherwise no results will be returned for that peroperty is you use LIKE predicate with fulltextsql.
I have a MOSS site where I have created custom content types and activated those on a document library. Now I want to use a custom XSL stylesheet with search results to pull back those documents and display the name of the custom content type assigned for each one.
I know how to create managed properties and map those, etc... but can not seem to find the built-in type that would have the name I assigned to the custom content types? You would think this would be simple - but simply using a built-in one like "ContentType" returns something generic and not the name of the custom type.
Any ideas?
The default content type managed property is mapped to multiple crawled properties, with the first one usually being the mime type. I think there is a way to get all values of a property rather than just the first one in the search results xsl, but if that doesn't work out you can always add a custom managed property that only maps to the one crawled property.