Setting 'summarization=false' does not disable the summarization flow step.

[sromoam]

Describe the bug
A clear and concise description of what the bug is.
When setting summariation to false in either the YAML or in the UI, the summarization step still appears in the workflow. This is a confusing user experience, even if the summarization step is disabled.
Having blank or unfulled summarization settings results in pipeline failures even when the step is disabled.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...' view edit configuration
2. Set the summarization active = false, and blank the other settings
3. reprocess document set
4. See errors in processing at summarization step.

Expected behavior
There should be no summarization step appearing in the state machine when you set the summarization step active to false.
The same should be true of other optional steps, including 'discovery', 'agent configuration' and 'assessment'.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[sromoam]

The default 'basic' YAML file is quite expansive for even a simple use-case. For instancve, the 'discovery' module, which should be totally optional, is effectively defaulted on in the default configuration.

[rstrahan]

Addressing this for now in the UI representation on the processing flow.

History note: At one point in the past we did implement conditional processing using choices in the statemachine, but the resulting large combinations of statemachine paths quickly became unwieldly / unmaintainable. It is much simpler to execute a linear flow, with each step performing according to the config settings.

However, I agree that in the UI we should clearly represent the steps that are disabled.

Adding 'NOT ENABLED' annotations for disabled steps in the UI Processing Flow in upcoming release v0.3.20 - see atached.

It's not perfect since it's driven from the current config, which may possibly have been altered since the document was processed, but it's a quick step in a better direction.

We can improve it further (in a future release) by enhancing the pipeline to attach a config 'snapshot' to each processed document workflow, so we have strong association between the document process and the exact configuration that was used for the process. I do think we should start capturing and preserving the config used for each document - for many reasons - in this case it will allow us to reflect the enabled/disabled steps from the historical config used, rather than the currently active config.

Here's how it looks with assessment and summarization both disabled..

The default 'basic' YAML file is quite expansive for even a simple use-case. For instancve, the 'discovery' module, which should be totally optional, is effectively defaulted on in the default configuration.

Separate issue.. cross refence to #87

[rstrahan]

Leaving issue open for tracking this:

We can improve it further (in a future release) by enhancing the pipeline to attach a config 'snapshot' to each processed document workflow, so we have strong association between the document process and the exact configuration that was used for the process. I do think we should start capturing and preserving the config used for each document - for many reasons - in this case it will allow us to reflect the enabled/disabled steps from the historical config used, rather than the currently active config.