Why are we removing these requirements, yet still testing them below?
(I know we had briefly discussed updated NIST guidelines several weeks ago - related? Generally, I'm keen to remove complexi...
If I recall from discussions with Justin, I don't think this is really about idempotency. I believe the reason is because board ED users cannot change compact-level permissions, so any value (even ...
If the API supported paging, these would at least trigger a re-fetch of the data. Does it make sense to have them just do that for now? If not, you could just have them `return false` & add comment...
Maybe, I was unsure about this.
Essentially, the ListContainer component requires these functions be passed in as props. I didn't want to make those props non-required + change ListContainer log...
Deferring full implementation till later. We're using this as a placeholder to represent the task of defining a more minimalist implementation for now.
Minor: Move this to the `// Reds` section.
Also, is this just a new color in the designs? Or did you have to create it to meet a11y? Ideally, we could use the same red we've been using for error...
Minor: The pattern up to now has been to declare computeds like stores, compact, user permissions & "high-level" things near the top of the computed block; as a means of making it easier to find in...
Same as earlier comment - existing patterns seem to be just as effective, and not require `any`.
Also, making sure `this.watchFormInputs()` is excluded on purpose.