fix: make status and mitre column optional

[degenaro]

Types of changes

• Hot fix (emergency fix and release)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation (change which affects the documentation site)
• Breaking change (fix or feature that would cause existing functionality to change)
• Release (develop -> main)

Quality assurance (all should be covered).

• My code follows the code style of this project.
• Documentation for my change is up to date?
• My PR meets testing requirements.
• All new and existing tests passed.
• All commits are signed-off.

Summary

Key links:

• Sonar coverage

Before you merge

• Ensure it is a 'squash commit' if not a release.
• Ensure CI is currently passing
• Check sonar. If you are working for a fork a maintainer will reach out, if required.

[AleJo2995]

@degenaro I might be wrong but is there a particular reason for creating 3 different test cases with almost the same steps being executed inside? I think we could reuse the code and just create a function called test_cis_xlsx_to_oscal_catalog_wo_columns or something similar and looping over the column values

[degenaro]

@degenaro I might be wrong but is there a particular reason for creating 3 different test cases with almost the same steps being executed inside? I think we could reuse the code and just create a function called test_cis_xlsx_to_oscal_catalog_wo_columns or something similar and looping over the column values

Thx for the comment. Keeping test cases separate makes them simple and clear. These test cases are provided to insure 100% coverage for the subject under test. There is no real advantage to rolling up into a single test case in terms of time, space or duplication.

[jpower432]

LGTM

[AleJo2995]

LGTM