Skip to content

Conversation

@Iwantexpresso
Copy link
Contributor

@Iwantexpresso Iwantexpresso commented Nov 26, 2025

Fixes #7264
Added number validation, similar to latitude longitude fields "between" filter, as well as negative validation to Range filter for Age

Previous behavior:

Screen.Recording.2025-11-26.at.1.58.02.PM.mov

Current behavior:

Screen.Recording.2025-11-26.at.2.00.41.PM.mov

Checklist

  • Self-review the PR after opening it to make sure the changes look good and
    self-explanatory (or properly documented)
  • Add relevant issue to release milestone
  • Add pr to documentation list
  • Add automated tests
  • Add a reverse migration if a migration is present in the PR

Testing instructions

  • Create new or open existing CO query, add age field and set filter to range
  • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)
  • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

@CarolineDenis CarolineDenis added this to the 7.12.0 milestone Dec 3, 2025
@Iwantexpresso Iwantexpresso requested review from a team December 3, 2025 15:19
Copy link
Collaborator

@emenslin emenslin left a comment

Choose a reason for hiding this comment

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

  • Create new or open existing CO query, add age field and set filter to range
  • Check if Range field properly checks for negative values
  • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)
  • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

Although an error is thrown with negative values, you can still type them in and you are allowed to have negative values on the forms, so what is the expected behavior? I don't imagine negative values are used; however, if they are accepted on the forms then shouldn't they be also accepted in the query? If this is the expected behavior that's okay, I just wanted to double check.

Saving Chronostrat time periods with negative values:

12-03_12.39.mp4

Age query:

12-03_12.40.mp4

Additionally, when you type in decimal values the field only briefly flashes red and then goes back to normal, what is the expected behavior here? If decimal values should be accepted than the field should not flash red, and if they should not be accepted then the field should stay red.

12-03_12.43.mp4

@github-project-automation github-project-automation bot moved this from 📋Back Log to Dev Attention Needed in General Tester Board Dec 3, 2025
Copy link

@kwhuber kwhuber left a comment

Choose a reason for hiding this comment

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

  • Create new or open existing CO query, add age field and set filter to range
  • Check if Range field properly checks for negative values
  • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)
  • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

I tested this on: uw_geo_collections_2025_09_09

I also ran into issues.

  1. Attempting to type in characters, I could not type any in except for "e". When I click outside the input box, the red highlight persists which I assume is correct!
Screen.Recording.2025-12-03.at.1.20.24.PM.mov

This same behavior persists when I begin my query with a number; I can still type an "e" after I enter a number and it highlights it red just like in the video above.

  1. Decimal values prompt the box to be highlighted red, but I think there is an issue where your fix is only reading the most recently inputed value. For example, when I only input "." and click outside the input box, it correctly stays highlighted. However, when I then input a value it knows is correct e.g. "1" and then click outside the box it removes the red highlight.
Untitled.mov
  1. After recognizing a decimal and highlighting it red, clicking outside of the input box then back into it and deleting the input carries an error into the next input. This does not get cleared until clicking outside of the input box with a valid entry. For example, if I enter "0.1", receive error, then delete, then enter valid input it still flags it as error.
Screen.Recording.2025-12-03.at.1.52.42.PM.mov

@Iwantexpresso
Copy link
Contributor Author

Iwantexpresso commented Dec 5, 2025

  • Create new or open existing CO query, add age field and set filter to range

    • Check if Range field properly checks for negative values

    • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)

    • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

Although an error is thrown with negative values, you can still type them in and you are allowed to have negative values on the forms, so what is the expected behavior? I don't imagine negative values are used; however, if they are accepted on the forms then shouldn't they be also accepted in the query? If this is the expected behavior that's okay, I just wanted to double check.

Saving Chronostrat time periods with negative values:
12-03_12.39.mp4

Age query:
12-03_12.40.mp4

Additionally, when you type in decimal values the field only briefly flashes red and then goes back to normal, what is the expected behavior here? If decimal values should be accepted than the field should not flash red, and if they should not be accepted then the field should stay red.
12-03_12.43.mp4

Hi!, I think the negatives part would've been form me misinterpreting the age filed and thinking of it as a non-negative field to be the expected behavior, I can revert that to match the chronostrat behavior, also I believe the expected behavior for querying even with a warning should be there at least according to what I saw from the Latitude Longitude warnings, but you should still be allowed to query, I Checked the code a bit and could not find save blocker implementations for the query button itself. I need to ask someone else to identify the correct behavior on this one. but as it was previously the behavior does match the Latitude longitude field ( excluding the non-negatives part)

@Iwantexpresso
Copy link
Contributor Author

  • Create new or open existing CO query, add age field and set filter to range

    • Check if Range field properly checks for negative values

    • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)

    • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

I tested this on: uw_geo_collections_2025_09_09

I also ran into issues.

1. Attempting to type in characters, I could not type any in except for "e". When I click outside the input box, the red highlight persists which I assume is correct!

Screen.Recording.2025-12-03.at.1.20.24.PM.mov

This same behavior persists when I begin my query with a number; I can still type an "e" after I enter a number and it highlights it red just like in the video above.

2. Decimal values prompt the box to be highlighted red, but I think there is an issue where your fix is only reading the most recently inputed value. For example, when I only input "." and click outside the input box, it correctly stays highlighted. However, when I then input a value it knows is correct e.g. "1" and then click outside the box it removes the red highlight.

Untitled.mov

3. After recognizing a decimal and highlighting it red, clicking outside of the input box then back into it and deleting the input carries an error into the next input. This does not get cleared until clicking outside of the input box with a valid entry. For example, if I enter "0.1", receive error, then delete, then enter valid input it still flags it as error.

Screen.Recording.2025-12-03.at.1.52.42.PM.mov

Hi Kaden, I have no idea what could be causing the only e at the moment ill try to recreate it on the same and different databases. And I think I know whats causing both of those bot the constant checking on any input and the carrying over of the error

  • Create new or open existing CO query, add age field and set filter to range

    • Check if Range field properly checks for negative values

    • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)

    • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

I tested this on: uw_geo_collections_2025_09_09

I also ran into issues.

1. Attempting to type in characters, I could not type any in except for "e". When I click outside the input box, the red highlight persists which I assume is correct!

Screen.Recording.2025-12-03.at.1.20.24.PM.mov

This same behavior persists when I begin my query with a number; I can still type an "e" after I enter a number and it highlights it red just like in the video above.

2. Decimal values prompt the box to be highlighted red, but I think there is an issue where your fix is only reading the most recently inputed value. For example, when I only input "." and click outside the input box, it correctly stays highlighted. However, when I then input a value it knows is correct e.g. "1" and then click outside the box it removes the red highlight.

Untitled.mov

3. After recognizing a decimal and highlighting it red, clicking outside of the input box then back into it and deleting the input carries an error into the next input. This does not get cleared until clicking outside of the input box with a valid entry. For example, if I enter "0.1", receive error, then delete, then enter valid input it still flags it as error.

Screen.Recording.2025-12-03.at.1.52.42.PM.mov

Hi Kaden, I just made some changes that addressed the constant negatives on block and the carried over warnings, It was due to my custom implementation that would handle both of these on its own, and after removing the check for negative numbers I was able to use the default parser properties to quickly fix these!

@Iwantexpresso
Copy link
Contributor Author

  • Create new or open existing CO query, add age field and set filter to range

    • Check if Range field properly checks for negative values
    • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)
    • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

I tested this on: uw_geo_collections_2025_09_09
I also ran into issues.

1. Attempting to type in characters, I could not type any in except for "e". When I click outside the input box, the red highlight persists which I assume is correct!

Screen.Recording.2025-12-03.at.1.20.24.PM.mov
This same behavior persists when I begin my query with a number; I can still type an "e" after I enter a number and it highlights it red just like in the video above.

2. Decimal values prompt the box to be highlighted red, but I think there is an issue where your fix is only reading the most recently inputed value. For example, when I only input "." and click outside the input box, it correctly stays highlighted. However, when I then input a value it knows is correct e.g. "1" and then click outside the box it removes the red highlight.

Untitled.mov

3. After recognizing a decimal and highlighting it red, clicking outside of the input box then back into it and deleting the input carries an error into the next input. This does not get cleared until clicking outside of the input box with a valid entry. For example, if I enter "0.1", receive error, then delete, then enter valid input it still flags it as error.

Screen.Recording.2025-12-03.at.1.52.42.PM.mov

Hi Kaden, I have no idea what could be causing the only e at the moment ill try to recreate it on the same and different databases. And I think I know whats causing both of those bot the constant checking on any input and the carrying over of the error

  • Create new or open existing CO query, add age field and set filter to range

    • Check if Range field properly checks for negative values
    • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)
    • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

I tested this on: uw_geo_collections_2025_09_09
I also ran into issues.

1. Attempting to type in characters, I could not type any in except for "e". When I click outside the input box, the red highlight persists which I assume is correct!

Screen.Recording.2025-12-03.at.1.20.24.PM.mov
This same behavior persists when I begin my query with a number; I can still type an "e" after I enter a number and it highlights it red just like in the video above.

2. Decimal values prompt the box to be highlighted red, but I think there is an issue where your fix is only reading the most recently inputed value. For example, when I only input "." and click outside the input box, it correctly stays highlighted. However, when I then input a value it knows is correct e.g. "1" and then click outside the box it removes the red highlight.

Untitled.mov

3. After recognizing a decimal and highlighting it red, clicking outside of the input box then back into it and deleting the input carries an error into the next input. This does not get cleared until clicking outside of the input box with a valid entry. For example, if I enter "0.1", receive error, then delete, then enter valid input it still flags it as error.

Screen.Recording.2025-12-03.at.1.52.42.PM.mov

Hi Kaden, I just made some changes that addressed the constant negatives on block and the carried over warnings, It was due to my custom implementation that would handle both of these on its own, and after removing the check for negative numbers I was able to use the default parser properties to quickly fix these! Also ideally these should've addressed the only being able to input e as i believe it was also being caused by my custom implementation!

Copy link
Collaborator

@emenslin emenslin left a comment

Choose a reason for hiding this comment

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

  • Create new or open existing CO query, add age field and set filter to range
  • Check if Range field properly checks for negative values
  • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)
  • (optional) test on other databases that have the Age field ( any db with Geology, Vertebrate Paleontology, or Invertebrate Paleontology collections should have it).

Looks good, my previous issues were fixed, although you might want to update the testing instructions as in a comment you said that negative values are accepted now.

As for non numeric values, 'e' is the only one that should be "accepted." 'e' can be added in other numeric fields so it is not an issue specific to this PR, although I am not sure if an issue has been written up for it.

@emenslin emenslin requested a review from a team December 9, 2025 19:58
Copy link

@kwhuber kwhuber left a comment

Choose a reason for hiding this comment

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

  • Create new or open existing CO query, add age field and set filter to range
  • Check if Range field properly checks for negative values
  • Check if Range properly checks for non-numeric values (i.e "weesnaw", "123.1.1" , "12num", etc.)

Thank you for the updates; Earlier failed cases are okay now!

@Iwantexpresso Iwantexpresso requested a review from a team December 12, 2025 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Dev Attention Needed

Development

Successfully merging this pull request may close these issues.

Age query 'Range' operator allows input of any character, causing errors

5 participants