Issues with the Advanced Search feature of OrgBook

[swcurran]

I tried the Advanced search with and found some issues vs. how I expected it to work. Some are specific problems, some may be how the features is intended to work.

1. In the credential type dropdown, the localization values are not displayed for the credential types:

2. In the name field there is autocomplete, which I don't think is how it is supposed to work. What is needed is a search that allows the user to set all the other parameters show the search results for that. If autocomplete is active, is it taking into account the other field settings? It's not -- when I type a string (e.g. "can") I get the same autocomplete whether the credential type field is set or not. If not, that eliminates the purpose of advanced search.

   • I want to search for a Cannibis retailer by (ideally) selecting the credential type and seeing all that match, or if I have to put in a search term, by selecting the credential type and putting in "cann" and seeing all companies with a matching name that possess that credential type (and historically or not).

3. I would have expected (although not clear) that I could leave the "Name" field blank to find all the companies that have a given credential type. With paging, this should work, I would think.

• Hitting "Search" with no value confusingly (to me) goes to the search screen without any data showing up.

[swcurran]

Hey @ianco -- wasn't sure what repo to use for this...

[WadeBarnes]

We should move this ticket to bcgov/aries-vcr since that's where the affected code lives at the moment.

[swcurran]

Is it in Aries or the OrgBook instance? I thought it was BC specific -- especially the lack of localization data. But I guess at least some of it is Aries VCR. I'm interested where the line is drawn.

I'll move it.

[ianco]

Options on indexing the BN to add to the search:

• if you configure the BN attribute as a "name" it will be indexed and will show up in the autocomplete, however OrgBook will randomly show either the "official" bc registry name or the BN "name"
• note that you can search by the BC company number, but it's not indexes as a "name" but as a "topic source id" - it doesn't show up in the autocomplete drop-down and has to be an exact match
• if you configure the BN number as a "category" it is treated as a "facet" (normally a restricted set of values) - it's searchable via the "credential search" (but not the "topic search" as it's not on the foundational credential); also the set of BN's will be included in the "/facet" versions of the api's (not desired behaviour)
• if we just treat the BN as an "attribute" we will need a new api to do a database search (vs a solr search) - see New api to query topics by attribute value #563

Desired behaviour?

• search similar to the "category" search (see the above PR)
• search similar to the "source id" (treat the BN like the BC company number for search purposes)

[swcurran]

My preference would be that Legal Name, BN and BC Company Number all work in auto-complete (e.g. are names) and that in the search results, anything that is flagged as a "name" appears in the search results. regardless what term was matched.

[amanji]

Just some thoughts to get the discussion rolling on this but please correct me if I'm wrong on anything.

In the credential type dropdown, the localization values are not displayed for the credential types:

The CredentialType model in aries-vcr has a description field that is populating what's displayed in the dropdown list of Credential Types. It looks like the description is populated using the credential schema name rather than some other field (like the actual description). I wonder if the the model needs to be updated to include a localized field that would help fix the issue, or if the credential schema is missing something (I'd have to look further into the schema on the deployed instance OrgBook BC)?

In the name field there is autocomplete, which I don't think is how it is supposed to work. What is needed is a search that allows the user to set all the other parameters show the search results for that. If autocomplete is active, is it taking into account the other field settings? It's not -- when I type a string (e.g. "can") I get the same autocomplete whether the credential type field is set or not. If not, that eliminates the purpose of advanced search.

Should autocomplete be enabled for advanced search? If so then it appears that the issue of indexing the BN comes into play here:

if you configure the BN attribute as a "name" it will be indexed and will show up in the autocomplete, however OrgBook will randomly show either the "official" bc registry name or the BN "name"

and

note that you can search by the BC company number, but it's not indexes as a "name" but as a "topic source id" - it doesn't show up in the autocomplete drop-down and has to be an exact match

The other option is utilizing the new category search feature (#563) and perhaps adding a field to search by BN (although one could question the UX of that when search already allows one to lookup topics by the BC Registries Number)

I would have expected (although not clear) that I could leave the "Name" field blank to find all the companies that have a given credential type. With paging, this should work, I would think.

I think this relates to using the secondary category search endpoint. By introducing another search function, would there need to be an additional control introduced to indicate what search to perform (i.e. either name, or category, or both)? In the case of both search type executed, which results take precedence, the name, or the category results? I haven't quite taken a look at that latest PR but I'm inclined to understand how the category search endpoint works.

I don't currently have reason to believe that adding BN as a facet would make sense since they are unique for all businesses.

My preference would be that Legal Name, BN and BC Company Number all work in auto-complete (e.g. are names) and that in the search results, anything that is flagged as a "name" appears in the search results. regardless what term was matched.

I would need to investigate further into how SOLR indexing works for autocomplete.

[swcurran]

I don't think there should be any auto-complete in advanced search, and that it be possible to not include any text in the search by name field in advanced search. At least one of the advanced search fields needs to be used and the results need to paged.

As noted -- my strong preference is that anything that is a unique "key" for an entity should be a "name" in Aries VCR in general, and therefore in OrgBook BC, Legal Name, BC Reg ID and BN are all "names". Likewise, I think an Aries VCR (not OrgBook BC, but OrgBook BC would use it) is that any topic result would include a "names" array, that would have each name listed.

Note that I'm talking about both the abstract data model (topics, categories, attributes) that Aries VCR supports (where Aries VCR is agnostic to the credentials issued to it) and specifically how that abstract model data is applied for the BC Registries use case.

[amanji]

In the credential type dropdown, the localization values are not displayed for the credential types:

Turns out, the issue here has to do with providing a localization label (ex label_en) for the credential_type configuration in services.yml. I suspect localization labels were added for the LCRB cred types but not for the other ones in OrgBook. I'm not sure if there is an endpoint specifically available on aries-vcr that allows for updating, but I can see the web hook handler that the controller registers schemas and cred types at startup. I would suspect a fix would simply involve an update to the OrgBook cred types to include a localized label.

[amanji]

Should we begin the process of porting API calls over to V3?

[swcurran]

Separate issue. Right now Advanced Search is broken, so we need that addressed first.

[ianco]

If we need to make any back-end API changes then we should make the changed in the V3 API's. I suspect we'll wind up with the advanced search using the V3 API's and the rest of the app still on V2

[swcurran]

Sorry - if that question was in the context of advanced search, absolutely, we should be using v3. I thought you are asking a more general question about the rest of the site/webapp.