Create and Update Concepts and Mappings

[paulsonder]

Background and context

This issue describes how an OCL user creates, update (and delete) an OCL resource (a Concept or Mapping).

OOUX

Objects: Concept and Mapping Type: Object interaction (creating an object or updating it via its form).

User Stories

As a: terminology implementor or publisher I want: create or update Concepts and Mappings using a simple UI So that: I'm able to maintain my Resources via the TermBrowser, reducing the need for external tools or files.

As a: terminology implementor or publisher I want: create or update Concepts and Mappings in context of a Search Result or Repository So that: I'm able to view content in list or card view in the same UX

As a: terminology implementor or publisher I want: utilise searchlight when picking from or searching a list of resources to complete the form So that: I have a consistent and larger workspace to locate the correct resource(s) with the necessary context (supporting information).

Design: UX / UI documentation

https://zpl.io/zwkrdpM

Handover notes

• Creating or Updating a Resource (Concept or Mapping) takes place in the 'Side Sheet' component
• Buttons in the Side Sheet are sticky.
• If a User saves the form, any validation should be triggered inline using the standard error messaging UI for M3 components
• When a User opens a dropdown, we should utilise the Searchlight component

[paynejd]

Starting a list of requirements/features that we might squeeze into the concept/mapping form redesign:

Concepts

• Concept name locale should take advantage of the source default/supported language fields
• First concept name should default to "Fully specified" and "preferred"
• Parent concept URLs -- replace this with a new component for selecting a parent concept within the same source

Concept Details Action Menu:

• Offer a way to assign a concept as the root hierarchy URL of a source, like possibly an action menu option to “Set as root of source hierarchy”

[jamlung-ri]

Note: Let's start in the context of Sources for the time being. We will want to keep the Collection context in mind but we will not design for it quite yet.

[paulsonder]

Design sprint activities described below:

[paulsonder]

@jamlung-ri Are there any additional product requirements you want to add before Sunny can get started on this?

[paynejd]

Ideas for consideration, but this is just a start -- these concept/mapping edit forms are the first place that we are actually advancing Smart Dictionaries for TBv3, so let's discuss.

Concepts

• [x] - Squeeze each concept name/synonym (Locale, Type, Name, External ID, Preferred) into a single line or use a table-based editing component?

• [x] - Some concepts have 100+ names

• [x] - We may want to consider upgrading our MUI to support a data grid (https://mui.com/x/react-data-grid/

• [x] - Concept ID, External ID, and name/description external ID fields should be "aware" of the repo's ID settings

• [ ] - The tool should help users define concepts according to best practices, eg:

• [x] - Pre-populate language selections based on repo defaults

• [x] - One (and only one) fully specified name (FSN) per name required

• [ ] - ...many more things to add here to help users create "Smart Dictionaries"

• [x] - Concept Templates -- this is not a major feature, and it would be awesome to launch TBv3 with this from the beginning -- e.g. user selects a concept template at the top of the form, and of course "Blank" is one of the options

Mappings

• [ ] - Add Mapping ID and External ID fields -- these are optional and can be editable based on a repo's ID settings -- these fields must be "aware" of the repos ID settings
• [x] - Remove "Concept Class" field
• [ ] - From Concept and To Concept do not always point to repos or concepts that OCL knows about, meaning these need to be pretty sophisticated fields to allow for all of the possibilities

Both

• [x] - Owner and source are not really part of a concept's attributes — these should be listed at the top, but not editable -- the owning source is set based on the context of where the user clicked on create, meaning that the entry point for creating a concept should ALWAYS be inside a repo, not in the global search

[paulsonder]

The following images show the Concept Detail View in Read, Edit and Create mode.

Read

Read w/ menu open

Edit mode

Create mode

[jamlung-ri]

Nice! I like this direction so far, and one potential addition that would help me is what it looks like specifically when the user is editing that long name in Edit Mode. For example, when the user is in Edit Mode and they click on the text of that long name, does that text become a text form box? Or does the user have to click the three dot menu on the right to edit that name specifically? A quick visual of what it looks like when I'm changing that specific name would help a lot.

[snyaggarwal]

@paulsonder Few more things to consider in designs:

• [ ] Edit Concept — Cannot edit ConceptID — Need to remove that field from design and/or reflect its disabled or you are editing Concept XXXX
• [ ] Auto ID assignment — ID will be auto assigned based on repo settings — can override it.
• [ ] Probably add URL of Concept where the concept will live.

[paulsonder]

Updated designs here: https://zpl.io/vn1GWY7

I will add the URL shortly

[jamlung-ri]

Dependent on #1830 to fully complete this user story