automation & sequence: fix use of default policies and set Sequence as default sequence policy

[kingthorin]

Overview

Modify automation and sequence to properly build and use a policy from policyDefinition if present in the plan. If neither policy nor policyDefinition are defined fall back to Default Policy or Sequence respectively.

Related Issues

n/a

Checklist

• Update help
• Update changelog
• Run ./gradlew spotlessApply for code formatting
• Write tests
• Check code coverage
• Sign-off commits
• Squash commits
• Use a descriptive title

[kingthorin]

I had to rename one of the UnitTest classes so that Eclipse would properly find it and run it as a JUnit test.

[kingthorin]

Still needs changelog and help updates I guess

[kingthorin]

Okay I think I'm caught up to all the feedback now 😉

[thc202]

There are still two cases that don't yet use the default policy, when the policyDefinition is present but it's an empty object and when not present at all.

I'm fine if this is merged without those two cases but we should fix them before releasing the add-ons.

[kingthorin]

1. when the policyDefinition is present but it's an empty object

Handled.

2. when not present at all.

I'm not exactly sure where to handle this. verifyParameters if both policy and policyDefinition are missing? (For the sequenceActiveScanJob anyway, I didn't check the generic one) ... Edit: or maybe in that method if policy isn't defined set it to Sequence it can then still be overridden by policyDefinition?

[psiinon]

Re 2. I think the seq ascan should always default to the Sequence policy we define.
So the order is (I think):

1. policy
2. policyDefinition
3. The seq policy defaul theyve specified by the options
4. The Sequence policy

[kingthorin]

Agreed, that's the way we're headed with this. The question for my point 2 above is where/how it should be handled within the code 😀

[thc202]

#5897 (comment)

It can be done in verifyParameters when policyDefinition is not present. (The policy should not matter for this case.) It's the same handling for both jobs. It might be better to call always the parsePolicyDefinition and keep the null strength handling internally.

[thc202]

I'd say in these cases we should use the defaults. The user is specifying something after all (even if not complete).

[kingthorin]

Done

[kingthorin]

Call parse from verify?

[kingthorin]

#5897 (comment)

It can be done in verifyParameters when policyDefinition is not present. (The policy should not matter for this case.) It's the same handling for both jobs. It might be better to call always the parsePolicyDefinition and keep the null strength handling internally.

Then I believe it's already covered. Both activeScanJob and sequenceActiveScanJob call parse in verifyParameters.

[thc202]

They need to call it always, currently when not present that method is not called and the null strength is not set.

[kingthorin]

Done