[vrotsc,vrotsc-annotations] (#336) Add Workflow Canvas Item for User Interaction Component

[akantchev]

User Interaction Workflow Item

The decorator is used to specify an user interaction workflow item.

Supported Parameters

• target - The name of the target to that user interaction workflow item is connected to. You can specify another user interaction workflow item as a target, thus chaining multiple user interaction components.

In order to bind inputs and outputs, you do it with the @In and @Out decorators.

Inputs

If you need to specify certain access limitation for the user interaction component you can specify them with @In decorators.
Those inputs are optional.

• security_assignees (type Array/LdapUser) - Any user from this array of users will be authorized to fill in this form.
• security_assignee_groups (type Array/LdapGroup) - Any user member of any of the groups will be authorized to fill in this form.
• security_group (type LdapGroup) - Any user member of this group will be authorized to fill in this form.
• timeout_date (type Date) - If not null, this input item will wait until date and will continue workflow execution.

Note that those parameters should match also the input parameters of the workflow.

Known Limitations for the Input Parameters

The names of the variables in the additional method decorators should be as following:

• security_assignees - for the security assignees parameter.
• security_assignee_groups - for the security assignee group parameter.
• security_group - for the security group parameter.
• timeout_date - for the timeout date parameter.

Outputs

You can specify multiple output variables that would hold the answer of the user interaction components.

Example Workflow

import {
    Workflow,
    In,
    Item,
    RootItem,
    UserInteractionItem,
} from "vrotsc-annotations";

@Workflow({
    name: "User Interaction",
    path: "VMware/PSCoE",
    description: "Adding user interaction parameters",
})
export class UserInteractionWorkflow {

    @RootItem({ target: "userInteraction1Enter", exception: "" })
    public start() {
        System.log("Starting workflow");
    }

    @UserInteractionItem({
        target: "userInteraction2Enter",
    })
    public userInteraction1Enter() {
        System.log("User interaction component 1 activation");
    }

    @UserInteractionItem({
        target: "userInteractionExit",
    })
    public userInteraction2Enter(
        @In security_assignees: LdapUser[],
        @In security_assignee_groups: LdapGroup[],
        @In security_group: LdapGroup,
        @In timeout_date?: Date,
        @In userInteractionAnswer?: string
    ) {
        System.log("User interaction component 2 activation");
    }

    @Item({ target: "end" })
    public userInteractionExit(@In userInteractionAnswer: string) {
        System.log("User Interaction exit");
    }

Checklist

• I have added relevant error handling and logging messages to help troubleshooting
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation, relevant usage information (if applicable)
• I have updated the PR title with affected component, related issue number and a short summary of the changes introduced
• I have added labels for implementation kind (kind/) and version type (version/)
• I have tested against live environment, if applicable
• I have my changes rebased and squashed to the minimal number of relevant commits. Notice: don't squash all commits
• I have added a descriptive commit message with a short title, including a Fixed #XXX - or Closed #XXX - prefix to auto-close the issue

Testing

End to end tests for the user interaction component were also added.

Related issue:

#336

[Michaelpalacce]

I don't agree with this approach. I am not going to approve these changes. If someone else wants to do so, feel free, I will remove my review then

Disimssing review as per reviewer request.

[Michaelpalacce]

I can't believe we merged this 😮

We are using the "Strategy Pattern" for this. The whole point it was done this way was so we can avoid inheritance... https://www.geeksforgeeks.org/favoring-composition-over-inheritance-in-java-with-examples/

Now we've created an entirely useless abstract parent, that easily could have been a function if we were so worried about duplication.

I am not saying to never use inheritance, but doing so in a Strategy pattern is... atrocious.

Not to mention the wrappers that were added to the parent class. The way it was done, completely breaks SRP.

Let's introduce more complexity for the sake of complexity in this "overly simple project", it boggles my mind.