Model Details and Model Version Details: add editable properties section, set up API patches for description, labels and properties

[mturley]

Closes RHOAIENG-2235 and RHOAIENG-2238
Followup to #2760

Description

• Implements the contents of the Properties section using a new ModelPropertiesDescriptionListGroup component which provides view/add/edit/delete controls
• Implements API patch requests when saving edits to Description, Labels and Properties (replacing the stub Promise for the former two)
• Adds input validation to ensure labels and property keys are unique. See "Input validation screencaps" below.
• None of these components/utils are specific to RegisteredModel, they work with ModelRegistryCustomProperties objects and generic T extends ModelRegistryBase objects, so it should be easy to reuse these for the ModelVersion detail page.
• Note that the patch requests must use the new getPatchBody utility in order to make sure the request isn't clearing other fields due to the way patches are performed in the API. We must supply all editable fields when patching an object even if we aren't modifying them all, but we can't supply some fields like the create/edit timestamps or we'll get 400 errors.

Demo screencaps

• Editing the Description of a RegisteredModel

  Screen.Recording.2024-05-02.at.3.22.26.PM.mov

• Editing the Labels of a RegisteredModel

  Screen.Recording.2024-05-02.at.4.00.16.PM.mov

• Editing the Properties of a RegisteredModel

  Screen.Recording.2024-05-02.at.4.02.56.PM.mov

Input validation screencaps

• When adding a new label, in addition to the existing validation that the label text must be no longer than 63 characters, we also now validate that a newly added label is unique (does not match any existing key in customProperties, whether that is a label or the key of a property in the table below). If the label is not unique, the modal submission is blocked and an error message appears:

  

• When editing an existing label, the same validation is applied. However, with the current beta version of PF editable labels, there is no way to express input validation errors while editing a label's text. As a workaround for now, if the user attempts to use an invalid label (either longer than 63 characters or matching an existing label/property), when they click away the change is not applied and the label remains as it was before they clicked it:

  Screen.Recording.2024-05-02.at.3.31.09.PM.mov

• When adding or editing a property, the same validation is applied to the property key. Errors in this case appear inline below the key input field:

  

cc @yih-wang @vconzola

How Has This Been Tested?

Go to Model Registry in the nav, click a registered model and click the Details tab. Play around with the edit controls on the Description, Labels and Properties sections. (see the screen recordings above)

Test Impact

Unit tests have been added for the new utility functions mergeUpdatedLabels, getProperties, mergeUpdatedProperty and getPatchBody. Cypress tests for all these views are to come soon.

Request review criteria:

Self checklist (all need to be checked):

• The developer has manually tested the changes and verified that the changes work
• Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

• Included any necessary screenshots or gifs if it was a UI change.
• Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

• The developer has tested their solution on a cluster by using the image produced by the PR to main

[manaswinidas]

Also, I cannot see the dragging functionality for description. As per the mocks

[vconzola]

LGTM. @mturley I think the way you're handling error cases is fine for now. I also like the enhancement you suggested in Slack. I assume that'll be in a future PR once UXD has a chance to review your proposal.

[mturley]

@manaswinidas I'm working on the overflow in the Properties section, but for the Description textarea I do get a draggable control in the bottom-right on Chrome. Although it should probably default to that 24-line height, I can change that.

[mturley]

@manaswinidas I addressed your feedback: the description textarea will now default to 24 lines and be resizable only vertically (I was missing the resizeOrientation prop), and the Properties section now properly wraps and truncates text:

Really good catch there, thank you!

[mturley]

/hold
we'll merge #2774 first

Comments addressed

[yih-wang]

Hi @mturley, thanks for all the work, they look really great! I got two comments regarding the current screens, but feel free to close this pr and address the comments in future enhancements.

• It seems that the validation for duplicated labels/properties occurs while the user is typing. This could be annoying if the user hasn't finished inputting and accidentally duplicates an existing label. I believe it would be better to validate this after the user submits the modal/row.
• I didn't see from the screen cap how it works if the properties are more than 5 and collapsed, and the user clicks 'add property' at this moment. Just to clarify, the ideal behavior would be for the collapsed list to expand, and the cursor to automatically locate to the newly added key field.

[lucferbux]

/unhold

there are ux comments so we might need to update the pr but we are not waiting on any other PR

[mturley]

Hi @yih-wang,

Thanks for the feedback! Let's make sure to follow up with a UX issue / discussion to improve this after this PR.

• I'm not sure how input validation works elsewhere in the dashboard, I think it would be important to be consistent with that. I implemented the real-time validation because it is simpler to implement that way in React and I've seen it done that way elsewhere, but we can certainly change that behavior. This is one area where I may need to keep my non-designer opinion to myself, but personally as a user I always hate when I don't see validation until after I submit something because it takes me longer to try multiple times than to get the proactive feedback as I type and make sure I'm doing it right the first time. But I think I may be the weird one here!
• Currently if you click "Add property" while the properties are collapsed, it puts the new row at the bottom of the currently shown rows without expanding the rest. That's something we could easily change.

[lucferbux]

Ok, so far everything seems great, I think there was still a discussion open right? But so far it looks great, just a small nit about refreshing data, we should use the right refreshing state for each component

[lucferbux]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gitdallas, lucferbux

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lucferbux]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mturley]

FYI, we have these followup issues based on the parts of the above feedback and Slack discussions that were not addressed in this PR:

• RHOAIENG-6994 - Model/Version Detail - Move "Add Label" out of edit mode
• RHOAIENG-6995 - Model/Version Detail - Show validation errors when editing existing labels
• RHOAIENG-6996 - "Add property" should expand existing properties and focus the input field