Bug Report - Editing Dates Can Cause Standardization Problem
LegacyUser
✭✭✭✭
Gordon Collett said: This bug or design problem was pointed out by Wayland in another post, but I wanted to re-post it here labeled as a bug report and to clearly demonstrate how the problem arises.
If a date exists and is standardized:
and someone edits that date to a new value:
and ignores the drop down menu, does not press enter, and does not press tab but clicks elsewhere on the screen, including in the Reason Statement box, the standardized value is not changed:
If the person is not paying attention and just saves, the new displayed value is shown on the page but, if a birth or death date, the old and still existing standard displays in the header:
This problem would be the same for dates other than birth and dates but it would be even hard to see. One would have to specifically check the standardized value.
Modification appears to be needed on how clicking outside the text entry box functions for dates. This should be done in a manner that it does not remove the function that clicking outside the text entry box for places has.
If a date exists and is standardized:
and someone edits that date to a new value:
and ignores the drop down menu, does not press enter, and does not press tab but clicks elsewhere on the screen, including in the Reason Statement box, the standardized value is not changed:
If the person is not paying attention and just saves, the new displayed value is shown on the page but, if a birth or death date, the old and still existing standard displays in the header:
This problem would be the same for dates other than birth and dates but it would be even hard to see. One would have to specifically check the standardized value.
Modification appears to be needed on how clicking outside the text entry box functions for dates. This should be done in a manner that it does not remove the function that clicking outside the text entry box for places has.
Tagged:
0
Comments
-
Amy Archibald said: I've noticed that editing the name of the person doesn't immediately update the header unless I refresh the page. This has been this way for me for at least all of 2020 and I think the last few months of 2019. I noticed a few months ago that it was also doing it with any birth date change. So I just refresh the page.0
-
gasmodels said: I do not believe refresh will resolve the issue Gordon is pointing out. The header uses the standardized date and the vitals show the visible date. In this case these are different and will always display differently.0
-
joe martel said: Gordon, you are suggesting that the edit control is misbehaving and has nothing to do with refresh of the person lifespan header right? If so its been communicated to the teams. Thanks0
-
Gordon Collett said: It's been two hours. Just went back to look at the page again. Nothing has changed and the displayed date and it's standardized version are still 225 years apart. Feel free to test it out yourself. You do have to follow the exact steps to do this.
1) Go to an entry that has an existing standardized date.
2) Open the edit box.
3) Type in a new date.
4) Click anywhere on the page outside of the date entry box. This is the only time it happens.
5) Save the new date.0 -
Gordon Collett said: Yes, an edit control that used to be very valuable many updates ago has now the potential to not update the standardized value properly. It was Wayland that first described this on another topic.
https://getsatisfaction.com/familysea...
He has seen several people trigger the problem by editing the date, leaving the drop down menu open because they see no need to click on what they just typed, and then immediately clicking into the reason statement box.0 -
Gordon Collett said: Stop! Wait! This is not a bug!
I woke up the morning and realized that this is a high powered featured that can be dangerous in the wrong hands but is a valuable replacement feature for one that disappeared a couple of major updates ago.
The date field used to be much better at accepting words and special characters while still proving correct standardized values. It isn't anymore and I've been missing that feature.
For example, in the oldest Norwegian parish registers, there are many entries that have no date, just the named Sunday or Feast Day, for example, Dominica 4 post Epiphan 1735. I really prefer to enter the date as it is written in the records because that is the real date. I then include, in editorial brackets [ ] my conversion of the date from a website that calculates these like this:
Dominica 4 post Epiphan [30 January] 1735
This used to provide on the drop down menu the choice to standardize as 4 January 1735 or 30 January 1735. It no longer does. All I get is this:
It works a little better if I use parenthesis.
But parenthesis have a different meaning than brackets.
However, if I enter just the converted date and standardize:
Then go back and enter the information it needs and click outside the data entry box, I preserve the correct standard:
When understood and used properly, this is an important feature.
Maybe what this actually needs is a warning box to pop up when one click out of the box instead of choosing from the drop down menu or using Tab or Enter:
0
This discussion has been closed.