Disabled (Informational-only) SSA Fields
S
Steve Monroe
Imagine a self-service action where some of the inputs are known from the context of the entity being operated on or the user. It would be nice to be able to show to the user these bits of information for verification but not allow them to change it by making the field grayed out and disabled.
Example: Promote a Build to the next environment. All the context is known from the Build e.g. version, service being deployed, and related story, current environment and thus next environment. Each of these fields will be automatically populated from the entity context and the fields grayed out.
It may also be nice to distinguish between when an SSA is operated from context i.e. from an entity versus from the self-service library without context. That knowledge of SSA origin could be used to dynamically set those fields as disabled or not without the need to duplicate the SSA, one for disabled fields when operated via context and one with enabled fields for when operated from the SSA library.
K
Kevin Ryan
I am running into something similar where I want to pass an additional entity that is related to the entity that the SSA was triggered on through to the backend. For my usage, I would rather these not even be defined as inputs but rather as "additional data" so that the SSA only has the entity as an input and the other data is automatically gathered and added to the run context.