Don't trigger unload protect when setting lat/long#3587
Merged
Conversation
Fixes #3584 The resource.set() function was setting an unload protect when intially loading lats and longs that were very precise. The intial value (string), was being set to a number which was not equal to the inital value. This led records to need saving even when they were just loaded (from QueryBuilder or other means)
bronwyncombs
reviewed
Jun 7, 2023
bronwyncombs
left a comment
There was a problem hiding this comment.
The save button is working appropriately
bronwyncombs
approved these changes
Jun 7, 2023
maxpatiiuk
approved these changes
Jun 9, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3584
To Test:
@maxpatiiuk As shown in the code comments, while not related to #3584, I stumbled across another issue. When rendering the Coordinate components, Specify parses the value (initially a string) to a Coord and then converts the Coord to a float and tries to set the once-string value to the new float.
If the value was precise, there may be a loss of precision during the conversion. While most institutions would likely never need values that precise, data integrity is still data integrity.
I was looking at possible solutions, and am considering Number().toFixed(), because we know the database precision for the field. I'll need to look into this more if it is that important of a problem.