-
Notifications
You must be signed in to change notification settings - Fork 28
BB2-4266 - C4DIC Endpoint #1428
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
base: master
Are you sure you want to change the base?
Conversation
…ub.com/CMSgov/bluebutton-web-server into clewellyn-nava/BB2-4266/C4DIC-endpoint
…ub.com/CMSgov/bluebutton-web-server into clewellyn-nava/BB2-4266/C4DIC-endpoint
| # return False | ||
|
|
||
| def has_permission(self, request, view): | ||
| # TODO: Why is this not being called? |
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.
has_permission is on the permissions.BasePermission, which is called by has_object_permission which is called on line 207 of generic.py in FhirDataView, which loops through self.get_permissions() which returns anything defined in the self.permission_classes (which is defined on line 60)
…ub.com/CMSgov/bluebutton-web-server into clewellyn-nava/BB2-4266/C4DIC-endpoint
JIRA Ticket:
BB2-4266
What Does This PR Do?
What Should Reviewers Watch For?
There is currently a failing unit tests because it expects the _format to be "json", but if you look at the https://sandbox.bluebutton.cms.gov/docs/openapi#/v1/fhirMetaData, it should /at least/ be application/json, and I propose it should be application/json+fhir everywhere we're making BFD calls.
Please look at the various TODO's, some of these are design decisions the team will have to make and live with, while some of them are proposed cleanups.
I have removed a lot of existing unnecessary code from when fhir server settings and fhir resource permissions were stored as objects in the database. I found no issues with my changes via unit tests and testclient testing, but take care to check permissions.
I've taken the liberty of sketching out what a drf ViewSet implementation of Patient would look like. Doing this made me realize some assumptions our API wrapper has that may need to be revisited if we go with the ViewSet, or push us away from it as a concept.
You should look to authenticate with a patient and mess with the scopes and URI to check that it works and doesn't work as expected.
If you're reviewing this PR, please check for these things in particular:
Validation
Unit tests pass, integration tests pass, local testclient works as expected. This shouldn't be a functional change.
For testing the C4DIC endpoint, you will need to authenticate with BBUser09995 (PW09995!@), as it has the C4DIC data populated.
What Security Implications Does This PR Have?
N/A
Any Migrations?
N/A