Spatial Tree - Id is included in search result though the Id is hidden about viewer-components-react HOT 5 OPEN

This happens because filtering is being done on the backend using default label rules, but ID suffixes are dropped on the frontend. I think suffixes should be dropped by modifying the ruleset instead.

Having said that, the @itwin/breakdown-trees-react package doesn't have a maintainer at the moment, so I'm not sure if we have anyone willing to work on this.

from viewer-components-react.

@grigasp I understand dropping the ID on frontend is the reason. But user says there is a specific case that has to be addressed. Say the user uses InstanceLabelOverride and sets the label to UserLabel. In the tree when the UserLabel could not be calculated then the value in 「Presentation.json」の「label.notSpecified」is displayed. User has set this value to "Not specified". This value is not searchable and this will occur in any tree not just @itwin/breakdown-trees-react package.
Take a look at below tree:

When I search using "Not specified" nothing shows up:

Whereas if just input "not" in the search box, the same node gets filtered:

User feels this is bit confusing for them. Is it possible to make the text that is displayed in the tree searchable. In this case "Not specified" should filter out to that one node.

from viewer-components-react.

This is an interesting problem...

As I mentioned earlier, filtering is being performed on the backend against the created hierarchy. The "Not specified" label is assigned to nodes that don't have a label, but instead of assigning an English string, we assign a localized string identifier (in this specific case - @Presentation:label.notSpecified@). The string gets translated to user's language on the frontend and the result may not even be close to the identifier (e.g. in Lithuanian it would be "Nenurodyta") and to make things worse - users could enter just a substring of that.

I think to make this totally correct we should:

1. Match user's input against localized strings used in the hierarchy.
2. In case there are matches, include their keys in the list of substrings we look for when filtering.

This is a bit more complicated than it may sound as the required APIs don't exist today - there's no way to get a list of all localized strings on the frontend for step 1 and the filtering request currently accepts only 1 filter string while we may need more for step 2.

I'm also not sure this is a big problem - wouldn't it be better to assign fallback values for labels to see at least some useful information instead of "Not specified"? E.g. another property like CodeValue or class label...

from viewer-components-react.

FWIW, I filed an issue in our backlog to make sure we support this situation in the new hierarchies builder implementation we've been working on lately.

from viewer-components-react.

Thanks for creating a backlog. I understand it is complex. Let me check the priority with user.

from viewer-components-react.