Previously, when a user selected a compliance policy with tailored rules,
the review page always showed the default profile customizations instead
of the policy-specific customizations.
Root cause: OscapProfileInformation component was only using the profile
endpoint (/oscap/{distribution}/{profile}/customizations) which returns
base profile rules, not the policy endpoint
(/oscap/{policy}/{distribution}/policy_customizations) which returns
customized rules.
Changes:
- Add useGetOscapCustomizationsForPolicyQuery export to backendApi
- Implement dual data fetching in OscapProfileInformation:
* Profile endpoint: for description and reference ID
* Policy endpoint: for customized packages, services, kernel args
Fixes the compliance policy customization display bug where edited
policy rules were not reflected in the image build summary.
Add unit tests for compliance policy customizations
Fix profile description title
Automatically enable FIPS mode when:
User selects OpenSCAP profile with FIPS enabled (e.g., DISA STIG)
User selects compliance profile with FIPS enabled and not customized off
- Add FIPS checkbox in openscap step
- Display FIPS status in review step
- Add unit tests to FIPS checkbox feature
This ensures security compliance for profiles that require FIPS mode
without manual user intervention.
The `import/order` rule isn't enough to sort import within a single import group alphabetically.
This adds `sort-imports` rule that handles the sorting within groups.
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.
Fixes#1985
This concatenates masked service to the disabled services so both get rendered in the "Disabled service" code block.
Test to check this was also added.
OpenSCAP profile info is now correctly loaded into the state and
verified to be in the final request with tests.
I modified the fixtures for the OpenSCAP profiles. My changes ensure we
have a Venn-diagram like overlap when changing from one profile to
another where one package is the same, one package is removed, and one
package is added. The same is true for the services and partitions. For
kernel args it is not so important as that is just a string (as opposed
to an array), so it is enough to be different.
I was able to eliminate a useEffect by replacing it with a lazy query
trigger function. Setting the second arg `preferCacheValue` to `true`
means that a request is only made if cached data is not available.
I modified the Redux reducers a bit to add some additional safety.
`changeFileSystemPartitionMode` is now responsible for initializing the
partitions field in the state by adding the root partition – previously
this was done in the components themselves by dispatching
`addPartition`. This reducer can always be safely dispatched – if the
mode is ‘manual’, dispatching it with a payload of ‘manual’ will not
result in any changes to the state.
`addPackage` is also safer now. When a package is added, the list of
packages is checked. If there is a package with an identical name, the
new package overwrites the previous package. This is useful because the
description may be different for the same package – for instance, when
adding an OpenSCAP package, we use a custom description (‘this package
required by OpenSCAP’).
For the UX the user doesn't really need to know that the services are masked,
rather than disabled in the backend. We can simplify this and show the masked
services as disabled.
this commit adds kernel arguments and enabled/disabled services to Oscap step.
and also add to Review step, add some tests to kernel and services as well.
Before, in the Oscap step, the drop down select menu was only listing profile_ids
Now, it shows the profiles names. When the user selects one, the details about the
profile are displayed under the selection, improving user experience.
FIXES# HMS-3087
