Skip to content
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

Make all state autocomplete options visible in occurrenceeditor #1718

Draft
wants to merge 3 commits into
base: Development
Choose a base branch
from

Conversation

NikitaSalikov
Copy link
Collaborator

@NikitaSalikov NikitaSalikov commented Sep 13, 2024

Before:

Screenshot 2024-09-13 at 1 37 47 PM

After:

Screenshot 2024-09-13 at 1 26 13 PM

Edge case with "USA":
Screenshot 2024-09-13 at 1 28 35 PM

Issue #1647:

@themerekat , the autocomplete feature for state/province works in a way that it grabs the parent value from country input field and checks for the possible geoterms within "geographicthesaurus" table where this country value ID == parentID. I assumed that you wanted the state/province input to show all possible options from our "geographicthesaurus" table if the country input is invalid (not in our "geographicthesaurus" table). Is that correct?

The issue with "USA":

Currently "USA" country input will be considered as valid which could be fixed but I'm not sure why we even need a separate value for United States in table as "USA" and not have a single value "United States" or "United States/USA" in the first place. This seems like a duplicate to me.

Changes Made:

  • made display all possible states/provinces if country is invalid,added a check for valid parent

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 squash and merged back into the master 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
  • 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 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.
  • Don't forget to delete your feature branch upon merge. Ignore this step as required.

Thanks for contributing and keeping it clean!

Copy link
Collaborator

@themerekat themerekat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this fixes part of the problem, but not the whole issue. There could be multiple valid values of a given country (USA, United States of America, United States, etc.), but they are all synonyms of a single name (United States, in this example). We want all the child geoLevel values for the accepted name to be listed. I.e., when USA is used, all the United States children show up.

@NikitaSalikov
Copy link
Collaborator Author

I think this fixes part of the problem, but not the whole issue. There could be multiple valid values of a given country (USA, United States of America, United States, etc.), but they are all synonyms of a single name (United States, in this example). We want all the child geoLevel values for the accepted name to be listed. I.e., when USA is used, all the United States children show up.

I see now! This is a bit of a different issue from what I've tried to solve. Thanks for clarification!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants