Enrollment CheckIn: Add SMSOptedIn field #1068
Merged
Conversation
This file contains 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
The API will now accept the SMSOptedIn field in the checkIn/cellphone endpoint. However, the field is not used or stored anywhere.
bennettforkner
approved these changes
Sep 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I added a new field, SMSOptedIn, to the data in the
PUT checkIn/cellphoneendpoint, to track whether the user opted in to receiving SMS communications from Gordon. This is required by Mogli SMS, and also by federal regulations I believe. This is related to CTS Ticket #175025, although it does not complete that ticket because currently theSMSOptedInfield is not used or persisted anywhere. I am working with the administrators of the other systems that collect this data to centralize and integrate the data.I also fixed the types on the
PUT checkIn/cellphoneandGET checkIn/holdsendpoints. They had been defined with a much too wide type encompassing all the data every touched by Enrollment Check-in, when in reality they only contain and need a much narrower subset of that data.I also created a new Stored Procedure,
GetEnrollmentCheckinHoldsto replace the previousFINALIZATION_GETHOLDSBYIDStored Procedure. The latter was over-complicated and retrieved more data than is needed.These are non-breaking changes, and the current UI will continue to work as is with this new API.