Extra fields for Person content type#70
Conversation
davisagli
left a comment
There was a problem hiding this comment.
@danalvrz Which issue is this for? I'd like to check what we need. For example if some of the fields are displayed for each result but not used as facets, then we can add them here with stored="true" but indexed="false" and it will have less overhead.
davisagli
left a comment
There was a problem hiding this comment.
Okay, I found it: https://gitlab.kitconcept.io/kitconcept/distribution-kitconcept-intranet/-/issues/296
The design shows facets for building and room. This seems a bit odd to me (is it a real use case to find everyone in "room 4" regardless of what building the room is in?) ... but if the design is correct, then we do need indexed="true" for contact_room and contact_building.
Note: the changes here will not take effect for existing content in solr until persons are reindexed. We should mention this in the release notes since we don't handle it automatically.
| <field name="contact_phone" type="string" indexed="false" stored="true" /> | ||
| <field name="contact_room" type="string" indexed="false" stored="true" /> | ||
| <field name="contact_building" type="string" indexed="false" stored="true" /> | ||
| <field name="job_title" type="string" indexed="false" stored="true" /> |
There was a problem hiding this comment.
@danalvrz I think you drew the wrong conclusion from my comment. These need to be indexed so that they can be used in facets, like is shown in the design.
You can merge once this is fixed. No release is needed; a new solr image will be built once this is merged to main.
|
@davisagli |
|
@sneridagh I was going by the Figma designs which show facets for searching by building and room. Maybe @danalvrz took my advice that that might not make sense and made a final decision to not add them. I don't know, since that decision wasn't written down in the ticket, and the design was not updated. We can come back to it if necessary, it's just nice to get it right the first time since it has to be reindexed if we change it later. |
No description provided.