Arvados

I don't have a problem with treating it like a string on the browser side if the editing form is being obnoxious.

However, (correct me if I'm wrong), I believe the "number" type did ensure that the "value" field would be set to a JSON number. With this change, "value" is now a string. There needs to be some fixup logic that converts parses values with dataclass "number" to actual numbers to avoid unpleasant surprises for downstream scripts.

Peter Amstutz wrote:

However, (correct me if I'm wrong), I believe the "number" type did ensure that the "value" field would be set to a JSON number.

This does not seem to be the case. Check out 4xphq-d1hrv-0lhbqyjab4g0bwp, which is a pipeline instance I created on 4xphq just now to test this, setting a number value using the existing Workbench code. That value is a string.

Brett Smith wrote:

Peter Amstutz wrote:

However, (correct me if I'm wrong), I believe the "number" type did ensure that the "value" field would be set to a JSON number.

This does not seem to be the case. Check out 4xphq-d1hrv-0lhbqyjab4g0bwp, which is a pipeline instance I created on 4xphq just now to test this, setting a number value using the existing Workbench code. That value is a string.

You got me there. Ok.

In render_pipeline_component_attribute if attrvalue is a number (not a string) then datatype does not get set and will be nil. However, it appears that the result is simply that "data-type" is not set on the x-editable control, and x-editable defaults to text anyway.

Go ahead and merge.