The Symbiota Virtual Flora/Fauna project develops on-line tools to aid the generation, exploration and management of biodiversity data (collection specimens, observations, images, checklists, keys, etc.). See also: http://bdj.pensoft.net/articles.php?id=1114 and https://symbiota.org/. For documentation, please visit https://symbiota.org/docs
check if date or identifiedBy are empty, if so - set them to default ones (s.d. and unknown)
If sciname is empty - display that it's skipped and continue the loop
Display the skippable errors (Duplicate values and Data too long) using try/catch to prevent the import process stop.
Pull Request Checklist:
Pre-Approval
[X] There is a description section in the pull request that details what the proposed changes do. It can be very brief if need be, but it ought to exist.
[ ] Hotfixes should be branched off of the master branch and squash and merged back into the master branch.
[X] Features and backlog bugs should be merged into the Development branch, NOTmaster
[ ] All new text is preferably internationalized (i.e., no end-user-visible text is hard-coded on the PHP pages), and the spreadsheet tracking internationalizations has been updated either with a new row or with checkmarks to existing rows.
[ ] There are no linter errors
[X] New features have responsive design (i.e., look aesthetically pleasing both full screen and with small or mobile screens)
[ ] If this PR makes any changes that would require additional configuration of any Symbiota portals outside of the files tracked in this repository, make sure that those changes are detailed in this document.
Post-Approval
[x] It is the code author's responsibility to merge their own pull request after it has been approved
[x] If this PR represents a merge into the Development branch, remember to use the squash & merge option
[ ] If this PR represents a merge from the Development branch into the master branch, remember to use the merge option
[ ] If this PR represents a hotfix into the master branch, a subsequent PR from master into Development should be made merge option (i.e., no squash).
[ ] If the dev team has agreed that this PR represents the last PR going into the Development branch before a tagged release (i.e., before an imminent merge into the master branch), make sure to notify the team and lock the Development branch to prevent accidental merges while QA takes place. Follow the release protocol here.
[x] Don't forget to delete your feature branch upon merge. Ignore this step as required.
Before:
After:
Duplicates example:
Note at the end example:
Changes made:
Pull Request Checklist:
Pre-Approval
masterbranch and squash and merged back into themasterbranch.Developmentbranch, NOTmasterPost-Approval
Developmentbranch, remember to use the squash & merge optionDevelopmentbranch into the master branch, remember to use the merge optionmasterbranch, a subsequent PR frommasterintoDevelopmentshould be made merge option (i.e., no squash).Developmentbranch before a tagged release (i.e., before an imminent merge into the master branch), make sure to notify the team and lock theDevelopmentbranch to prevent accidental merges while QA takes place. Follow the release protocol here.Thanks for contributing and keeping it clean!