Fix Update SSP and Component Definition to Display Profile Modifications #146
Conversation
When resolving a profile, modifications will now be set. This allows for SSP and Component Definition to display control modifications from imported profiles.
Changes in how we get modifications for each imported profile makes these tests no longer needed. Both the component definition and ssp rely on OSCALControlImplementationImplReq to display modifications.
tuckerzp
requested review from
rgauss,
kylelaker,
Bronstrom,
hreineck,
zclarkEDC,
kkennedy26 and
snorouzzadeh
|
I am assigning @hreineck to hopefully address comments in my absence. |
@rgauss could you clarify the intended behavior? seems this does not need to display any parameter constraints. It's currently calling |
In #75 acceptance criteria we see:
I'm not sure what you mean by "the default Component url doesn't have any Both the SSP and the Component Definition viewers should display those parameter constraints so that a user can immediately see whether the parameter value they've entered is within those constraints rather than having to navigate to the Profile. |
Fixed a typo, and modified the conditional around the call to the Control Prose functions in `OSCALControlProse` in order to have the parameter constraints display on mouse hover when applicable in the Component Viewer.
Change the way the `isLoaded` state variable is set to fix an issue where modifications would not render in the Component Viewer. `isLoaded` was being set to true upon the modifications for the first Control Implementation being resolved, which was causing the state to be "loaded" when not all the modifications were loaded. Added a `pendingProcesses` counter to track when all of the implementations have had their modifications resolved before setting the isLoaded state.
Made changes to address test and linter failures: Added a conditional around `processesToRun` to deal with cases where `componenents` is undefined or not an array. Addressed linter issues; got rid of `--` operators and `==` operator.
Changed the check for pending processes to a cleaner map/reduce function. Removed the unnecessary check for when `components` is not an array; to make this work, the test data was changed to the correct format in which `components` is an array instead of an object.
Minor change to a conditional in control part; combines these redundnant expressions.
Minor change to the conditional on the `pendingProcesses` variable to make things a bit cleaner.
|
@hreineck, looks like this still has conflicts to be resolved. Other than that looks good. |
|
@kylelaker, this look OK now? |
|
@hreineck Thanks again for taking this for me! Great job! |
This PR is a fix to #124 and should hopefully closes #75
This reworks
ProfileResolverto savemodificationsper imported profiles.SSPandComponent Definitionshould now properly displaymodificationsonly when given an imported profile.Tests have also been changed. Changes in how we get
modificationsfor each imported profile makes these tests no longer needed. Both theSSPandComponent Definitionrely onOSCALControlImplementationImplReqto display modifications. My reason for thinking these tests are unneeded is really due to how we pass modifications down toControlmaking it redundant to check on multiple levels that modifications are passed down. I would like if we can confirm that I am right in doing this as I still consider myself fairly new to the tests.