[Social Work] - Enhance technical documentation#1705
Open
landonshumway-ia wants to merge 8 commits into
Open
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR updates backend design documentation to describe expanded system behavior: RID/CUID identifiers, provider data model changes, license ingestion for single-state licensees, home-state and privilege generation rules, adverse action and investigation effects, notification behavior, and audit logging distinctions. ChangesBackend design documentation and ERD updates
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
backend/social-work-app/docs/design/README.md (1)
438-496: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winMake the home-state rule internally consistent.
Lines 438-443 require an active/eligible paired single-state license before a multi-state license can become home, but lines 491-496 say the newest paired MSL wins even if it is inactive or ineligible. Those rules conflict; please split “selection” from “privilege generation” or tighten the wording so readers can tell which check actually governs behavior.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/social-work-app/docs/design/README.md` around lines 438 - 496, The home-state wording is inconsistent because one section says a paired multi-state license must be active and eligible to become home, while the later “One-home-state-per-license-type enforcement” says the newest paired MSL always wins even if inactive or ineligible. Update the README to clearly separate home-license selection in the ingest/home-state flow from privilege generation in the runtime section, using the existing headings like Privilege Runtime Generation for Multi-State Licenses and Home State Changes to make it explicit which rule applies where. Tighten the selection language so the home-state rule matches the actual behavior, and leave the eligibility requirement only for generating privileges.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@backend/social-work-app/docs/design/provider-data-model-erd.mmd`:
- Around line 11-12: `PROVIDER.providerId` is now defined as `uuid`, but related
ERD entities still declare the same field as `string`, creating an inconsistent
contract across the diagram. Update the `providerId` field type in the affected
entity definitions (`LICENSE`, `LICENSE_UPDATE`, `PROVIDER_UPDATE`,
`ADVERSE_ACTION`, `INVESTIGATION`, and `PRIVILEGE`) to match
`PROVIDER.providerId`, and verify the corresponding entity symbols stay aligned
everywhere the field is shown. If any relationship is intentionally different,
add an explicit note in the ERD near the affected entity name to make the
exception clear.
In `@backend/social-work-app/docs/design/README.md`:
- Line 125: Update the README summary for the re-upload behavior so it matches
the full `licenseUpdate` schema used elsewhere. In the description tied to the
existing license record update flow, expand the categorized history record types
beyond `renewal`, `deactivation`, and `other` to also include encumbrance,
investigation, and home-jurisdiction-change updates, using the same
`licenseUpdate` terminology as the record schema.
- Around line 347-358: The CUID issuance flow in the ingest design needs to be
constrained to eligible multistate licenses, not every multi-state upload.
Update the description around ingest.py and publicCompactIdentifier so it
explicitly says the handler must first verify the license qualifies for
multistate authorization before generating the CUID, and only then write it to
the Provider Record; keep the “generate once if unset” behavior tied to that
eligibility check.
---
Outside diff comments:
In `@backend/social-work-app/docs/design/README.md`:
- Around line 438-496: The home-state wording is inconsistent because one
section says a paired multi-state license must be active and eligible to become
home, while the later “One-home-state-per-license-type enforcement” says the
newest paired MSL always wins even if inactive or ineligible. Update the README
to clearly separate home-license selection in the ingest/home-state flow from
privilege generation in the runtime section, using the existing headings like
Privilege Runtime Generation for Multi-State Licenses and Home State Changes to
make it explicit which rule applies where. Tighten the selection language so the
home-state rule matches the actual behavior, and leave the eligibility
requirement only for generating privileges.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8f7cc88c-f79a-4cca-9378-f498db26be52
⛔ Files ignored due to path filters (3)
backend/social-work-app/docs/design/provider-data-model-erd.pngis excluded by!**/*.pngbackend/social-work-app/docs/design/provider-data-model-erd.svgis excluded by!**/*.svgbackend/social-work-app/docs/design/users-arch-diagram.pdfis excluded by!**/*.pdf
📒 Files selected for processing (2)
backend/social-work-app/docs/design/README.mdbackend/social-work-app/docs/design/provider-data-model-erd.mmd
Collaborator
Author
|
@jlkravitz This is now ready for your review. Thanks |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We received a request from the chair of the Social Work commission for further technical documentation. It was determined with @KbisonCSG to deliver technical documentation for the following elements of the request:
This enhances our existing technical design documentation and ERD to cover these aspects of the system.
Closes #1702
Summary by CodeRabbit