Forward connections chips width is too forgiven

[ddelpiano]

SCKAN.Composer.mp4

As per video and title, the chips are messing with the entire layout if the content in the chip to render is too much.

[stappan]

Can we modify the chip to instead use the short name for the linked population? @ddelpiano that is, instead of the rdfs label?

[ddelpiano]

Can we modify the chip to instead use the short name for the linked population? @ddelpiano that is, instead of the rdfs label?

@stappan what about if the short name is not available yet? let's assume a KS which did not go through the entire curation flow, this won't have a short name yet since it's created upon exporting it the first time based on the population set that was given to this. Thanks

[stappan]

@ddelpiano If no NLP-ID (short name) is available, can we use the composer statement number (ks)?

[ddelpiano]

Sure, that is available since the beginning.
If we want conditionally the short name (if available) and when not the KS id then is between 4-6 hrs.
if always the KS id it's 2 hours (easier change, the endpoint already provide that info).

[stappan]

I prefer KS id. This will be a prioritized effort when we do the next set of hours, @ddelpiano thanks!

[stappan]

Please add this task to the next sprint. @ddelpiano

[stappan]

This effort would help resolve the challenge of selecting WHICH forward connection is the correct one - currently, the knowledge statement ID is listed in the preview, but adding the short name would help a ton.

add to acceptance criteria:

1. include short name below the KS ID in the search card preview (right panel; where green line is)
2. remove the second instance of the status (red circle in screenshot); keep pill at top of right panel.