Open krocheck opened 1 month ago
I have no problem with this being done.
Perhaps for a release or two (or forever?) we should keep the internal:custom_
around for compatibility? But without the definition, so that they won't show up in the ui.
They could be implemented so that internal:custom_X
has a value of $(custom:X)
, to simplify setting the values (we use this 'trick' elsewhere, to get the $(this:page_name)
and $(this:step)
to be correctly reactive)
Responds, in part to #2812 by moving custom variables from
$(internal:custom_...)
to$(custom:...)
. Checks are added to maintain backwards compatibility with legacy names.If we want to move forward I'll get the rest of the action items executed.
My main reason for attempting this is that with the addition of
$(this:...)
, it seems logical to me to make this change. The fact thatcustom
isn't a reserved word in v2.x is concerning, but I think is quite the edge case for someone to completely rename an instance tocustom
. But that can be investigated for upgrade mitigation ... though scrubbing the variables might become difficult.TODO:
custom
instance name mitigation in v2-v3 upgrade