Suggestion/edit control implementations UI

[rgauss]

This suggestion PR begins to simplify what information needs to be passed between components and moves the main editing capabilities to OSCALControlProse so that parameter inputs can be rendered inline in the prose.

[rgauss]

This is incomplete at the moment as it doesn't handle statementByComponents that don't yet exist and the onSuccess, onError page behavior isn't tied in yet.

I'll continue working on it.

[rgauss]

This is definitely worth starting to look at. I'll give a pass of more comments for explanation and move it out of draft state soon.

[kylelaker]

I haven't really looked into JSX/React bits here but there is a little bit of cleanup that we might be able to do to make some of the null handling a little cleaner. Mostly leveraging ?? and ??=.

[rgauss]

For this and similar changes, implementedRequirement contains implReqStatements so we don't need to pass around both.

[rgauss]

Since we're not using the simple field a more generic onRestSuccess was used instead.

[rgauss]

This is ready for a look.

[kylelaker]

Maybe this should have been a request on an earlier PR but looking into this a little more, the result request is structured like:

PUT /system-security-plans/cff8385f-108e-40a5-8f7a-82f3dc0eaba8/control-implementation/implemented-requirements/aaadb3ff-6ae8-4332-92db-211468c52af2

{
  "control-id": "...",
  "statements": [...],
  "uuid": "..."
}

But according to the specification (localhost:8080, source), the request needs to have a wrapping object with an "implemented-requirement" key:

{
  "implemented-requirement": {
    "control-id": "...",
    "statements": [],
    "uuid": "..."
  }
}

[kylelaker]

Also to be totally clear, other than the minor issue with the request object structure, this is absolutely lit!! I am so looking forward to getting the service implementation done because this is awesome!

[rgauss]

Maybe this should have been a request on an earlier PR but looking into this a little more, the result request is structured like:

PUT /system-security-plans/cff8385f-108e-40a5-8f7a-82f3dc0eaba8/control-implementation/implemented-requirements/aaadb3ff-6ae8-4332-92db-211468c52af2

{
  "control-id": "...",
  "statements": [...],
  "uuid": "..."
}

But according to the specification (localhost:8080, source), the request needs to have a wrapping object with an "implemented-requirement" key:

{
  "implemented-requirement": {
    "control-id": "...",
    "statements": [],
    "uuid": "..."
  }
}

Good catch, fixed.

[kylelaker]

Approved! Thanks for the work on this. Because this is going into another feature branch, this can be merged (well... it could have before too); I'll leave it up to you whether you want to merge it or wait for another review.

[rgauss]

@mikeisen1, want to make sure you have a chance to ask any questions here. Let me know if you'd like to go through it together.

[mikeisen1]

@mikeisen1, want to make sure you have a chance to ask any questions here. Let me know if you'd like to go through it together.

Let's discuss it during standup tomorrow? I have taken a look through, but a quick discussion would be nice before merging this.