Patternfly6 handles the grid for description lists slightly differntly
to Patternfly5. Add custom css to change the behaviour to match PF5 and
get the items in the review step to align properly
This splits the policy and profile selectors as they're drifting apart.
Instead of querying the customizations attached to the profile, query
the customizations attached to the policy, as these take into account
tailoring. As a result unnecessary customizations won't be added.
The Intercom team has some ideas about helping new users determine which
security profile is right for them. Tracking differentiates between
"vanilla" OpenSCAP and Compliance so that any messages from Intercom can
be targeted.
Refactor the OpenSCAP on-premise availability check. Add the check to
the component so we run the check everytime the step is loaded. The
benefits to this is that if the user installs the packages, they won't
need to reload the page to use the OpenSCAP step. The downside is that
the check is not very quick, so a spinner was added just to indicate
that the check is running.
The openscap customizatoins endpoint for on-prem is quite slow since it
has to call the run the oscap tool to generate the customization
options. Running this request lazily, as we do for the service, is too
slow, so we can just prefetch the customizations for on-prem.
Create the boilerplate function for getting the Oscap profiles. We will
need to make a call to the `oscap` binary to get this information. So
we will leave it empty for now.
This adds the kernel append input. New arguments can be added by pressing the "Add" button or hitting Enter after the argument.
The kernel arguments linked to a selected OpenSCAP profile are rendered in a category marked as "Required by OpenSCAP" and are read only.
The Insights compliance support reuses most of the existing OpenSCAP
step.
Depending on the state of the feature flag, it will show radio buttons
allowing users to switch between regular openscap and Insights
compliance.
Removing the server store makes the way we handle data going in and out
of the wizard state more consistent. Each customisation is mapped into
the wizard state and pulled out when generating the blueprint
payload.
When the services and kernel customisations are implemented, this
information will need to be stored inside of the wizard state anyway.
Lastly this will make implementing a compliance step easier for edit
mode, removing the need to write to the wizard state from within the
server store when only a compliance policy id is available (on the
review page), which would be used to fetch the profile ref id, which
would in turn be used to fetch the customisations not stored in the
wizard state.
