Add paleo fields to the Data Editor Search Form

[NikitaSalikov]

Changes Made:

• Added Paleo fields to the Record Search Form's fields selector
• Added Paleo update functionality to Batch Update Tool (?)

Batch Update Issue:

@egbot , as we previously discussed, there's an issue with omoccurredits table (OccurrenceEditorManager starting line ~2007):
omoccurredits table doesn't have paleo fields columns. Should we add them to the table?

Currently the code is skipping the INSERT INTO omoccurredits table if Paleo fields are present. Not the final solution, just for testing.

Pull Request Checklist:

Pre-Approval

• 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 PR'd using the merge option (not squashed) into the hotfix branch.
• Features and backlog bugs should be merged into the Development branch, NOT master
• 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
• New features have responsive design (i.e., look aesthetically pleasing both full screen and with small or mobile screens)
• Symbiota coding standards have been followed
• If any files have been reformatted (e.g., by an autoformatter), the reformat is its own, separate commit in the PR
• Comment which GitHub issue(s), if any does this PR address:
  https://github.com/orgs/BioKIC/projects/6/views/28?visibleFields=%5B37887625%2C%22Title%22%2C%22Assignees%22%2C37442248%2C69347678%2C%22Status%22%5D&sortedBy%5Bdirection%5D=&sortedBy%5BcolumnId%5D=&pane=issue&itemId=79647516
• 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

• It is the code author's responsibility to merge their own pull request after it has been approved
• If this PR represents a merge into the Development branch, remember to use the squash & merge option
• If this PR represents a merge into the hotfix branch, remember to use the merge option (i.e., no squash).
• 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 merge from the hotfix branch into the master branch use the squash & merge option
  • a subsequent PR from master into Development should be made with the merge option (i.e., no squash).
  • Immediately delete the hotfix branch and create a new hotfix branch
  • increment the Symbiota version number in the symbase.php file and commit to the hotfix branch.
• 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.
• Don't forget to delete your feature branch upon merge. Ignore this step as required.

Thanks for contributing and keeping it clean!

[ljwalker]

omoccurredits table doesn't have paleo fields columns. Should we add them to the table?

This seems like a good suggestion to me.

[ljwalker]

Original notes from discussions between SSH dev+Lindsay:

• Need to discuss complexity of searching for age-related values, with consideration for who will be using this form (data managers). E.g. if searching on "Late Cretaceous", do you only want records where the hand-keyed value is "Late Cretaceous", and thus so you can batch edit these values, or do you want to recall all records with child relationships to "Late Cretaceous", e.g. "Santonian", "Coniacian", etc.
• Will need to test thoroughly with respect to the batch editing vs. pure searching tools.

Responses to questions posed above from GEO OSE/paleo PI team (from 2024-12-12):

• Enable searching on specific age-related ranks, e.g. eon vs era vs. period, as well as earlyInterval and lateInterval.
• Being able to search on exact values and ranges of values would be ideal.
• Generally, more comprehensive searching/querying options is more desirable than less for this user interface.
• Is there a way to ensure that the Batch Replace tool does not allow addition of illogical values, as will be the case on the Occurrence Editor?
  • Does batch editing of earlyInterval or lateInterval values make sense? (i.e. These fields may behave similarly to sciName, which you currently cannot batch edit. Would a bulk data ingestion be a better way to update these values in mass?)

(Note that this feedback is specific to the Data Editor Search Form/not related to the Public Search form.)