@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Rebuild custom field indexes when rebuilding standard/fulltext search indexes

Summary:
Ref T4379. Fixes T4359. Currently, `bin/search index` does not rebuild CustomField indexes. This is because they aren't really part of the main search index. However, from a user's point of view this is by far the most logical place to look for index rebuilds, and it's straightforward for us to write into this secondary store.

At some point, it might be nice to let you specify fields as "fulltext" too, although no one has asked for that yet. We could then dump the text of those fields into the fulltext index. Ref T418.

Test Plan: Used `bin/search index --type proj --trace`, etc., and examination of the database to verify that indexes rebuilt. Reindexed users, tasks, projects.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4359, T418, T4379

Differential Revision: https://secure.phabricator.com/D8185

+35 -3
+2
src/applications/maniphest/search/ManiphestSearchIndexer.php
··· 81 81 time()); 82 82 } 83 83 84 + $this->indexCustomFields($doc, $task); 85 + 84 86 return $doc; 85 87 } 86 88 }
+2 -3
src/applications/people/search/PhabricatorUserSearchIndexer.php
··· 17 17 $doc->setDocumentCreated($user->getDateCreated()); 18 18 $doc->setDocumentModified($user->getDateModified()); 19 19 20 - // TODO: Index the blurbs from their profile or something? Probably not 21 - // actually useful... 22 - 23 20 $doc->addRelationship( 24 21 $user->isUserActivated() 25 22 ? PhabricatorSearchRelationship::RELATIONSHIP_OPEN ··· 27 24 $user->getPHID(), 28 25 PhabricatorPeoplePHIDTypeUser::TYPECONST, 29 26 time()); 27 + 28 + $this->indexCustomFields($doc, $user); 30 29 31 30 return $doc; 32 31 }
+3
src/applications/project/search/PhabricatorProjectSearchIndexer.php
··· 17 17 $doc->setDocumentCreated($project->getDateCreated()); 18 18 $doc->setDocumentModified($project->getDateModified()); 19 19 20 + $this->indexSubscribers($doc); 21 + $this->indexCustomFields($doc, $project); 22 + 20 23 // NOTE: This could be more full-featured, but for now we're mostly 21 24 // interested in the side effects of indexing. 22 25
+23
src/applications/search/index/PhabricatorSearchDocumentIndexer.php
··· 106 106 } 107 107 } 108 108 109 + protected function indexCustomFields( 110 + PhabricatorSearchAbstractDocument $doc, 111 + PhabricatorCustomFieldInterface $object) { 112 + 113 + // Rebuild the ApplicationSearch indexes. These are internal and not part of 114 + // the fulltext search, but putting them in this workflow allows users to 115 + // use the same tools to rebuild the indexes, which is easy to understand. 116 + 117 + $field_list = PhabricatorCustomField::getObjectFields( 118 + $object, 119 + PhabricatorCustomField::ROLE_APPLICATIONSEARCH); 120 + 121 + $field_list->setViewer($this->getViewer()); 122 + $field_list->readFieldsFromStorage($object); 123 + $field_list->rebuildIndexes($object); 124 + 125 + // We could also allow fields to provide fulltext content, and index it 126 + // here on the document. No one has asked for this yet, though, and the 127 + // existing "search" key isn't a good fit to interpret to mean we should 128 + // index stuff here, since it can be set on a lot of fields which don't 129 + // contain anything resembling fulltext. 130 + } 131 + 109 132 private function dispatchDidUpdateIndexEvent( 110 133 $phid, 111 134 PhabricatorSearchAbstractDocument $document) {
+5
src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php
··· 591 591 // need it to be up to date once the next page loads, but if we don't go 592 592 // there we we could move it into search once search moves to the daemons. 593 593 594 + // It now happens in the search indexer as well, but the search indexer is 595 + // always daemonized, so the logic above still potentially holds. We could 596 + // possibly get rid of this. The major motivation for putting it in the 597 + // indexer was to enable reindexing to work. 598 + 594 599 $fields = PhabricatorCustomField::getObjectFields( 595 600 $object, 596 601 PhabricatorCustomField::ROLE_APPLICATIONSEARCH);