Good call out, initially I had it as an optional field, but there's no reason it shouldn't be required. All of our current configuration files have it included, so I will remove this check and we'l...
@jlkravitz Sorry I was just confirming why we do this. This is something we do across the codebase.
This is just a sanity thing so that we can cleanly define what the properties are going to be ...
Yes, your understanding is correct. I don't see any cases where that would not be true for our data model but, now that you point it out, I don't think I want this limitation hiding in the code her...
Yeah, we can talk through separator and b64 alphabet character choice when we do a design view. Ultimately, it doesn't matter a lot what we choose for separators vs 62nd, 63rd b64 characters, as lo...
Just need to check my understanding here: with the way this is structured, it suggests that the base license and privilege records will ALWAYS come first in the array before any update records for ...
This right here makes me wonder if we should consider choosing other separators if we need to have logic like this... Are there not other options we could use that wouldn't require this?
This is a pretty critical piece, as whatever pattern we choose we will essentially be locked into forever to determine the update records by hash. I am trying to walk through any drawbacks with thi...
We should also have a log statement showing that we are restoring the record and what the change would have been. Given that we don't expect this code to get exercised very often, we should be fine...
it may be helpful to have a log message here noting that we are deleting something, so we at least have some paper trail of what record would have shown up in the system
We should leave a comment here explicitly calling out why we append the provider privilegeJurisdictions update last, so no one ever moves it to an earlier step in the algorithm.