gh-529 Add tree modal to catalogue item search screen

[aaronforshaw]

Closes #529

• Change model-tree-selector.component so that the input group can be hidden when not needed. Default the visibility to true, so there is no impact on existing usages of the component.
• Create a new modal component which includes the tree selector, with the input group hidden
• Add a button 'Choose catalogue item' to the search filters, which opens this new modal
• Add a method contextualSearch method to CatalogueSearchService in order to limit the search to the item selected from the tree (see caveats in comments below).

Observations which could be raised in separate tickets:

• there seems to be no endpoint which searches within a terminology or codeset
• the endpoint to search data classes seems to only allow searching of a root data class within a data model

[pjmonks]

@aaronforshaw This is just an idea, don't know how effective it will be. But I've been working on a branch in mdm-resources - feature/mdm-ui-gh-418. There are some changes there which allow a resource for model domains - Data Model, Terminology, etc - to implement a defined search() function/endpoint. The idea then is that the UI can then filter by domain type and return a common object to search with, e.g.

getSearchableResource(domain: string): SearchableResource => {
  if (domain === 'dataModels') {
    return this.resources.dataModel;
  }
  if (domain === 'terminiologies') {
    return this.resources.terminology;
  }
  /// etc...
}

// ...

const resource: SearchableResource = getSearchableResource('dataModels');
resource.search(...);

This is because there are 2 things which I don't like about the current ContentSearchHandlerService:

1. The lack of type definitions - no idea what inputs/outputs are expected
2. The repetition - once the domain is determined, effectively the same operation happens.

This may not be perfect though, I'm not sure about the Data Class search since that requires more parameters to locate the Data Class in the catalogue.

[pjmonks]

Is it better to combine these into another interface type, since they are all related? e.g.

export interface CatalogueSearchContext {
  domainType?: string;
  id?: string;
  label?: string;
  parentId?: string;
  dataModelId?: string;
}

export interface CatalogueSearchParameters {
  context?: CatalogueSearchContext;
  // etc...

[aaronforshaw]

I tried this as yes, it seems neater, but then realised it takes a lot of work to pack and unpack the context parameters to and from the query string. So I ended up reverting to the original approach.

[pjmonks]

Fair enough

[pjmonks]

The dialog with the model tree selection looks good. You might want to set a maxHeight on the dialog when opening it though, it may be possible that the tree control grows big enough to push the dialog contents "Cancel" and "OK" off-screen so the user can't actually continue.

[aaronforshaw]

I know what you mean, but the tree view seems to come with a vertical scroller in a fixed height container (I haven't figured out where the height is set).

[pjmonks]

You're right, somehow the tree view height is restricted enough to not go beyond screen boundaries, I've seen that in action now.

[pjmonks]

If the ContentSearchHandlerService is being modified, I think a lot of improvements could be made along the way:

1. Types on parameters
2. Correct return type
3. Date validation is repetitive
4. Actual search operation is repetitive - see my idea in the main conversation thread.

[aaronforshaw]

I got a bit nervous about modifying ContentSearchHandlerService as it is used in several other parts of the UI. So I have added a new contextualSearch method to CatalogueSearchService. This new method uses your idea from the main thread, with special handling for searching a Data Class.

It seems that the backend search service for Data Classes only allows the root Data Class within a Data Model to be searched. So I have also added a doNotShowChildDataClassesoption to the tree, the stop a user from expanding the root data class.

[pjmonks]

@aaronforshaw Some more things I found while testing (don't know if you know these already):

1. When I select any Data Model as the context, an incorrect HTTP request is sent:

POST http://localhost:8080/api/dataModels%7D/4bf88abe-166c-4328-9e45-2678a2aedd7f/search

The domainType part of the URL seems to include a } character in it, causing a 400 response. The query string in the page URL looks correct, so I'm not sure where this is being introduced.

2. Open the dialog to select a model. If you click any Data Model, the "OK" button is enabled. But click a Terminology, Code Set or Reference Data Model and it won't be enabled. But, click on a Data Model and then click on a Terminology, Code Set or Reference Data Model and the "OK" button is enabled, suggesting you can select any domain type.

[pjmonks]

@aaronforshaw Please ignore my comment on incorrect HTTP request URLs, I found the cause was down to my own local changes.

[aaronforshaw]

Regarding the issue of the tree not properly enabling the selection of ReferenceDataModel, Terminology and CodeSet, I have added ReferenceData to the list of elements accepted by the tree. Terminology and CodeSet can be added in the same way (see the line [accepts]="['Folder', 'DataModel', 'DataClass', 'ReferenceDataModel']"in catalogue-item-select-modal.component.html, but oddly although a request to a sensible looking endpoint, such as /api/terminologies/{terminology_id}/search, is made, the backend seems to perform a full catalogue search. I don't see backend search methods for terminologies or code sets. This could be investigated further under a separate ticket perhaps.

[pjmonks]

This looks great, thanks @aaronforshaw 👍

When I was testing I found a few bugs around the search, but I don't think they are related to your changes, I'll create separate issues for them.

Approved ✔️