An LTI 2 tool proxy declared enabled capabilities which generate their associated parameter when a launch occurs. However, variable parameters should also be used as implicit capabilities; just ones which are passed in custom parameters rather than an existing LTI 1 parameter. These implicit capabilities are not being included when parsing a custom parameter to check for supported substitution variables to be translated into their representative value.

So, for example, a tool proxy which includes the following parameter for a message with a type of "basic-lti-launch-request":

which is launched from a link which adds a custom parameter of:
loginname=$User.username
will not have the value of the custom loginname parameter substituted because the capability was not included in the enabled_capability section of the tool proxy. The code should check both this section and the variable parameters for a complete list of enabled capabilities and hence, in this example, the loginname parameter should have had its value substituted because the capability is supported implicitly.

This only affects 2.8+.