Draft Item Security & Search Results Security Trimming
The content access account of MOSS search should have a read-only access to content. In some cases that is not enough – there is a list level setting to limit the visibility of draft versions of list items to only the ones with edit permissions. This means that the content access account cannot index the draft versions. So if you have a document with the latest version being 0.x it is totally invisible in search. If you have a document with the latest version being 1.x you will only see the version 1.0 in search results.
The first reaction to overcome this would be to ignore the best practice and grant edit permissions to content access accounts. This allows indexer to crawl the latest draft version of the document. In SharePoint, the so-called “security trimmer” takes care of cleaning the search results and showing the user only the search results he is allowed to see. Somehow the draft item security setting is ignored by the security trimmer – apparently because it is a library level setting instead of being in the document access control list. This means that the latest draft version of the document will be indexed and shown in the search results for the user with only read permissions. But when user clicks the search result link of the document in question, he/she either gets a “access denied” error (if there are no major versions published) or the latest major version.
To sum this up, there seems to be only bad alternatives when using draft item security to require edit permissions to view drafts. Either not have draft versions indexed at all, or to elevate content access account with edit permissions, have the draft versions indexed but get problems with the search results security trimming.
Popularity: 2% [?]
[...] SharePoint Blog Post From SharePoint Security – Google Blog Search: In SharePoint , the so-called “ security trimmer” takes care of cleaning the search results [...]
[...] Draft Item Security & Search Results Security Trimming (SharePoint Blues)The content access account of MOSS search should have a read-only access to content. In some cases that is not enough – there is a list level setting to limit the visibility of draft versions of list items to only the ones with edit permissions. This means that the content access account cannot index the draft versions. So if you have a document with the latest version being 0.x it is totally invisible in search. If you have a document with the latest version being 1.x you will only see the version 1.0 in search results. [...]
Microsoft has made a related KB article: http://support.microsoft.com/kb/2304855 . Apparently this refers to content access account having the default read permissions.
I *don’t* want viewers to be able to see draft versions in their search results, but whenever the latest version of the document is a draft version *no* version of the document appears in the search results (even though there’s been a previous published version).
The document library is configured for major and minor versioning, require approval for publishing, require checkout to edit.
Most frustating! This is on the IW demo vhd.
Martin
[...] http://www.sharepointblues.com/2010/03/17/draft-item-security-search-results-security-trimming/ [...]
[...] to some blog posts like here and here , this happens [...]
Martin, have you gotten a workaround to your problem? We are encountering the exact problem.
Thanks so much.
Martin , Betty
I found a working solution at :
http://extreme-sharepoint.com/2011/10/04/sharepoint-search-isecuritytrimmer/
Hope it helps
Thanks
I’m revisiting this at present.
I’m not sure what config I used before. Here’s the behaviour I currently get:
Draft Item Security is set to “Only users who can edit items”
Content Crawler has Full Read user policy for the web app.
Once the content is crawled, and I’m searching (as a viewer), I get the version 1.1 of a doc in the results page, but clicking on it gives me the 1.0 version.
If I have a doc at version 1, crawl it, (correct version gets found), then update it, crawled version (v1) is shown in results, but updated version shown when I click it (if I’m an editor). If I’m not an editor, I only see the published version
Now another crawl happens (it’s already in index, but there’s a version 1.1 in the library now). Now when I search for this doc, the published version is shown in the search results, and when clicking through, I see the published version if I’m not an editor, and I see the new draft if I am an editor.
It seems to me that the state of the documents at crawl time is key. In addition, in order for the search results to make sense, it’s important that the documents are crawled in each state they go through. So it’s no good if the first time a doc is crawled, it’s at v1.1. It needs to have been crawled at v1.0.
It looks like the crawled state of the doc is used for showing in the search results, but the actual document is shown when you click through – and this maybe the latest draft if you are an editor.
What’s wierd is that the crawled state can show the draft version even though the crawler isn’t supposed to see that version. I update the doc again (to version 1.3), this time the non editor is the first to search it. They see the 1.2 version in the search results. Clicking through, they still see v1.0.
Editor sees 1.3. So before we crawl the lastest version, we have a more unusual situation where the version shown in the search results can be 1.2, editors click through to see 1.3 and non editors click through to see 1.0. Nice!
It would appear the config of the “Draft Item Security” does not effect the search crawler.
I’ve looked at the isecuritytrimmer a little, and I’m dubious about it’s value because of when it’s applied (at query time), and what it does (show/not show the search result). If the search result contains draft versions when the crawler should be able to see draft items, the security trimmer isn’t going to help.
Martin
Martin
[...] to some blog posts like here and here , this happens [...]
[...] to some blog posts like here and here , this happens [...]
geiledamen is the right place for lonley guys to chat for free with hot local ladies
White screen website tools are essential for web developers to diagnose and fix issues causing a blank display. These tools help identify problems in the code, such as broken scripts, missing files, or server errors. By providing detailed error messages and debugging options, they enable developers to quickly pinpoint the root cause and implement necessary fixes. Utilizing white screen tools can save significant time and effort, ensuring websites run smoothly and efficiently, thus enhancing user experience and reliability. https://whitescreen.dev/
The security trimmer appears to overlook the draft item security setting since it is specified at the library level rather than in the document access control list. See: Texas factoring