-
Notifications
You must be signed in to change notification settings - Fork 53
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
Occurrence controller record id accommodation #2292
base: API-updates
Are you sure you want to change the base?
Occurrence controller record id accommodation #2292
Conversation
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.
Tested and lgtm!
$occurrence = $this->getOccurrence($id); | ||
if (!$occurrence) { | ||
return response()->json(['error' => 'Occurrence not found'], 404); | ||
} | ||
if($occurrence){ | ||
if(!$occurrence->occurrenceID) $occurrence->occurrenceID = $occurrence->recordID; | ||
if($request->input('includeMedia')) $occurrence->media; |
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.
@Atticus29, Given the current implementation for including inputs, should we prompt that it should be "1" / "not zero" in /documentation?
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.
@NikitaSalikov what do you mean?
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.
@Atticus29, I mean adding to description something like this:
1 = Include media
0 or omitted = Do not include media
Or is it too much and should be obvious?
Description
This PR addresses the following in the API Audit doc:
The occurrence/foo endopoints now accommodate occid, occurrenceID, and recordID as identifier inputs.
Pull Request Checklist:
Pre-Approval
master
branch and PR'd using the merge option (not squashed) into thehotfix
branch.Development
branch, NOTmaster
Post-Approval
Development
branch, remember to use the squash & merge optionhotfix
branch, remember to use the merge option (i.e., no squash).Development
branch into the master branch, remember to use the merge optionhotfix
branch into themaster
branch use the squash & merge optionmaster
intoDevelopment
should be made with the merge option (i.e., no squash).hotfix
branch and create a newhotfix
branchhotfix
branch.Development
branch before a tagged release (i.e., before an imminent merge into the master branch), make sure to notify the team and lock theDevelopment
branch to prevent accidental merges while QA takes place. Follow the release protocol here.Thanks for contributing and keeping it clean!