Changes made to SiteTree.ShowInSearch are not propagated to Solr

[phptek]

Describe the bug

Related to #143. Changes made to a page via the "Show in search?" checkbox do not seem to be propagated back to Solr. This seems to affect such pages being included in search-results when "SiteTree_ShowInSearch" is listed as an exclusion (See the "Additional Context" section below). Regardless of how many times I check/uncheck the box, the value of "SiteTree_ShowInSearch" remains false, and the page in question does not show in search results within the Silverstripe application in question.

• Re-running ./vendor/bin/sake dev/tasks/SolrConfigureTask": Changes nothing
• Reviewing the search admin in the CMS: No additional warnings or errors
• Removing/commenting "'SiteTree_ShowInSearch' => 0," from $exclusions (See below), and I can see the desired page in results within Silverstripe (Obviously the equivalent field in Solr itself remains unchanged)

Using: Module dev-master @8377d6f3

To Reproduce

Scenario #1: The "Show in search?" checkbox is checked:

1. [OK] Uncheck the "Show in search?" checkbox under a page's "Settings" tab within the CMS
2. [OK] Select the "Publish" button
3. [OK] Observe that the SiteTree.ShowInSearch field in the DB is set to "0"
4. [OK] Observe that the "SiteTree_ShowInSearch" field within Solr's UI, for a search for the page in question shows "SiteTree_ShowInSearch":false

Scenario #2: The "Show in search?" checkbox is unchecked:

1. [OK] Check the "Show in search?" checkbox under a page's "Settings" tab within the CMS
2. [OK] Select the "Publish" button
3. [OK] Observe that the SiteTree.ShowInSearch field in the DB is set to "1"
4. [FAIL] Observe that the "SiteTree_ShowInSearch" field within Solr's UI, for a search for the page in question shows "SiteTree_ShowInSearch":true (It shows false)

Expected behavior

I should be able to check/uncheck the "Show in search?" checkbox at will, and after publishing I should be able to see/not-see the page included in listings accordingly and that the value of the "SiteTree_ShowInSearch" facet/field changes accordingly within Solr's UI with each change.

Screenshots

N/A

Desktop (please complete the following information):

Same as previously reported issues.

Smartphone (please complete the following information):

N/A

Additional context

Search logic:

$exclusions = [
    'SiteTree_ShowInSearch' => 0,
    'File_ShowInSearch' => 0,
    'File_ClassName' => Image::class,
];

$index = Injector::inst()->create(MyIndex::class);
$query = SearchQuery::create()
        ->setStart($start)
        ->setFields($params[0])
        ->setTerms($params)
        ->setRows(self::$results_per_page)
        ->setExclude($exclusions);
$result = $index->doSearch($query);

app/_config/search.yml:

Catalyst\MyProject\Search\MyIndex:
  MyIndex:
    Classes:
      - SilverStripe\CMS\Model\SiteTree
      # We exclude "Image" subclasses in querying logic. See PageController::results()
      - SilverStripe\Assets\File
      - DNADesign\Elemental\Models\BaseElement
    FulltextFields:
      - Title
      - forTemplate
      - LeftColumn
      - RightColumn
      - Content
      - Intro
    FilterFields:
      - SubsiteID
      - ShowInSearch
      - ClassName

Looking at the logic a little, I see that when dumping out $update in SolrCoreService::doManipulate() the following output is received for checking/unchecking respectively (See attached files). I note that in "check.txt", the "fields" sub-array is populated with fields/data, but "uncheck.txt" isn't. Having thought about this for a second, it pretty much explains nothing (!!) seeing that regardless of checking/unchecking, the field-value stored in Solr still doesn't change (Assuming it's supposed to).

check.txt uncheck.txt

[Firesphere]

This is related to your custom filter. ShowInSearch is ignored on update, because a false setting will remove an item from Solr.

I would suggest removing the field. It's not necessary anymore to have this field manually configured in your index. Index-time already takes care of this.

[Firesphere]

This issue is a non-issue, due to implementation error on the dev side. The value is not supposed to be controlled from a Solr perspective.