-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: display remove control elements #733
Conversation
The MarkupMultine method is used instead of the Markuline in the getTextSegment method because this is where we handle prose part. However, this method add an empty line at the begining which does not align well with the placeholder label. This empty line should be remove.
Your branch is up to date with 'fork/mpemy/display-remove-control-elements'. Changes to be committed: modified: src/components/OSCALControlProse.js Fixing the failing build due to linting issue. The line of code that was causing this issue have been addressed. There was method MarkupLines that was added and then removed because it was not needed I just forgot to delete it that is why lint was failing because I was importing a component that was not used and was inexistent. I have simply deleted that reference.
…emy/oscal-react-library into mpemy/display-remove-control-elements merging these two branches so that I can complete this commit and fix the failing build
… symbol is contains in json prose.
First gather all removed items and display them below the added items. Also implemented the strike-line to highlight the fact that these items are removed
… also committing changes related to feat #91 support include-all and exclude-control
…ast commit. Have modified the code to make sure the props.modificationDisplay is not undefined before trying to access its children
@mpemy can you provide a screenshot of this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far! I had a few clarifying questions.
@@ -42,13 +42,30 @@ function getAlterAddsOrRemovesDisplay(addsElements, addsLabel, controlPartId) { | |||
Name: {item.name}, Value: {item.value} | |||
</Typography> | |||
)); | |||
let removedTypographies = null; | |||
if (addsLabel === "Removes ") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If addsLablel === "Removes "
is it really an adds label? Same for addsElements
.
The function documentation also describes the addsLabel
as a boolean variable which makes this more confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This label should be string, I changed it to the more descriptive addsRemovesLabel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this string comes from
oscal-react-library/src/components/OSCALControlModification.js
Lines 145 to 163 in 57b305b
if (alter.adds) { | |
[addsDisplay, len] = getModifications( | |
controlPartId, | |
props.controlId, | |
alter.adds, | |
"Adds " | |
); | |
modLength += len; | |
} | |
// Get all remove modifications | |
if (alter.removes) { | |
[removesDisplay, len] = getModifications( | |
controlPartId, | |
props.controlId, | |
alter.removes, | |
"Removes " | |
); | |
modLength += len; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to have some discussion on the overall design here. I'd need to look into the issue and actual json
structure a bit more before I could be too prescriptive on best solution, but I am thinking we may need to change how we are displaying removed elements.
I am requesting changes until we can talk more on this.
* @param {String} controlPartId Control part ID to match | ||
* @returns html object | ||
*/ | ||
function getAlterAddsOrRemovesDisplay(addsElements, addsLabel, controlPartId) { | ||
function getAlterAddsOrRemovesDisplay( | ||
addsElements, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this only the adds
elements?
I think you could change a lot of the addsorremoves
to be alters
. So altersElements
, altersLabel
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mpemy I wanted to bump this. I still think that addsElements
is not a very descriptive variable name here.
@@ -42,13 +42,30 @@ function getAlterAddsOrRemovesDisplay(addsElements, addsLabel, controlPartId) { | |||
Name: {item.name}, Value: {item.value} | |||
</Typography> | |||
)); | |||
let removedTypographies = null; | |||
if (addsLabel === "Removes ") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this string comes from
oscal-react-library/src/components/OSCALControlModification.js
Lines 145 to 163 in 57b305b
if (alter.adds) { | |
[addsDisplay, len] = getModifications( | |
controlPartId, | |
props.controlId, | |
alter.adds, | |
"Adds " | |
); | |
modLength += len; | |
} | |
// Get all remove modifications | |
if (alter.removes) { | |
[removesDisplay, len] = getModifications( | |
controlPartId, | |
props.controlId, | |
alter.removes, | |
"Removes " | |
); | |
modLength += len; | |
} |
I pushed changes for my two issues #89 and #91 in this branch. I am sorry it may be confusing when reviewing, moving forward each issue will have its own branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking over this, it seems like we only are dealing with things being removed by-id
. Looking at the remove outline, it seems we can also remove by name, class, item-name, and ns.
The acceptance criteria for #89 does not explicitly say we need to all of them, but it also doesnt say to just do by-id
. Would this be a big change in this pr?
Overall though this looks a lot better, I am starting to wonder if maybe we push refactoring some of this code to a separate issue. It seems like a lot of this needs to be reworked when we rework profile resolution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so I think I am good with the overall approach here! There are just some specific code cleanups to resolve. I don't love how many times we return basically the same
<Typography>
{props.label} {prose}
{props.modificationDisplay}
</Typography>
But I suppose we can always refactor that later...
It will be necessary to pull in the changes from the |
Co-authored-by: Kyle Laker <klaker@easydynamics.com>
Co-authored-by: Kyle Laker <klaker@easydynamics.com>
Co-authored-by: Kyle Laker <klaker@easydynamics.com>
Co-authored-by: Kyle Laker <klaker@easydynamics.com>
… into mpemy/display-remove-control-elements
Co-authored-by: Kyle Laker <klaker@easydynamics.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the work on this and for the iterations from review! I think at this point we're good to go ahead and merge. I still want to make sure that in the future we handle profile resolution more holistically; however, we have a separate ticket to implement that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mpemy I had a few comments on things that were most likely lost in the sea of comments.
Since a lot of this will need refactoring, I am ok with the fact that we did not add unit tests for this. Would you be able to create an issue to test your added functionality at some point?
* @param {String} controlPartId Control part ID to match | ||
* @returns html object | ||
*/ | ||
function getAlterAddsOrRemovesDisplay(addsElements, addsLabel, controlPartId) { | ||
function getAlterAddsOrRemovesDisplay( | ||
addsElements, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mpemy I wanted to bump this. I still think that addsElements
is not a very descriptive variable name here.
Dismissing this so I don't hold up review after my changes are addressed.
@mpemy can you send a link to that issue on this pr? I will move forward with merging once that is done. I just don't want to forget to add tests for this later. |
@tuckerzp these are the unit test issues: |
This pull request is for the Display remove control elements in Profile.
For testing this implementation, you can use this FedRAMP profile.
https://gist.githubusercontent.com/mpemy/9ea8e9b285cc9198ded3fa46d4154850/raw/9969488e66064281e8394305d352ae73cb60d9ec/Correct_rev4_LI-SaaS-baseline_profile.json
Closes #89
Closes #91