Links variables value manipulation

[ryhorB-epam]

Is it possible to add the ability to manipulate variables in references, for example, to use string functions. Now there are several variables ${status.startedAt} ${workflow....} but unlike variables {{}} there is no example of manipulation with the value of variables in ${}.
For example:

links: |
- name: Workflow link
  scope: workflow
  url: https://logs-storage/${status.startedAt.Y}/${status.startedAt.m}/${status.startedAt.d}

is converted to https://logs-storage/null/null/null and I would like to https://logs-storage/2022/01/03. It is possible to use the sprig functions, but it is not yet clear how.

[ryhorB-epam]

in Links these expressions don't work

url: https://logs-storage/{{=sprig.substr("0", "4", status.startedAt)}}

i got https://logs-storage/{{=sprig.substr("0", "4", status.startedAt)}}

url: https://logs-storage/{{=sprig.substr('0', '4', status.startedAt)}}

i got https://logs-storage/{{=sprig.substr('0', '4', status.startedAt)}}

url: https://logs-storage/{{=sprig.substr("0", "4", ${status.startedAt})}}

i got https://logs-storage/%7B%7B=sprig.substr(%220%22,%20%224%22,%202022-01-04T07:14:04Z)%7D%7D

[sarabala1979]

Is status.startedAt input parameter?

[ryhorB-epam]

No, this is variable from https://argoproj.github.io/argo-workflows/links/

[hadilou]

For anyone else wondering how to properly use sprig functions within your yaml check #8499 (comment)

[agilgur5]

Sorry that this never got a proper answer. You cannot do any manipulation of the links configuration at this time. It is a static string with substitution only, no expressions.

I'm not entirely sure why it was designed as such (it predates me), but the substitution is done in the front-end, which is notably in TS, not Go. Whereas Workflow variables are substituted in the Go back-end. So they don't share code. That's also why the syntax is different.
Notably, this is a configuration of the Server, not of a Workflow the Controller touches, so it is the odd one out in more ways than one.

In the future, it may be a good idea to use the same expression templating system by the Server here, but that would be a breaking change at this point in time.