Going to a record set triggers a form change

[realVinayak]

Describe the bug
If you click on 'Record Sets', then I am shown the list of record sets for that user. Try going from one record set to another and I get the dialog message 'This form has not been saved' even if I didn't change anything. A major issue because I wanted to know if I accidentally changed anything or not. This is in production by the way.

To Reproduce
Steps to reproduce the behavior:

1. Click on 'Record Sets' on the menu
2. Click on any record set
3. Click on 'Record Sets' again and go to another record set
4. The dialog 'This form has not been saved.' shows up.

Expected behavior
Shouldn't trigger the form change. Or at least tell me what changed.

[realVinayak]

The url in the screenshot: https://osuorton3823-edge.test.specifysystems.org/

[realVinayak]

Happens in Chrome, Edge and Firefox

[maxpatiiuk]

You have an unsaved form behind the dialog.
Opening the dialog is fine and doesn't trigger the unload protect dialog.
Actually clicking on a record set would replace the form with a record set, thus unload protect dialog is triggered to warn you about this.
Not a bug.
Though, if you think this is a UX issue, do you have suggestions on improving this?

[realVinayak]

Not showing the save dialog if there actually weren't changes! I discovered this while on production database and thought I changed the form

…

On Tue, Mar 28, 2023, 20:26 Max Patiiuk ***@***.***> wrote: Closed #3259 <#3259> as not planned. — Reply to this email directly, view it on GitHub <#3259 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOSKLYXO3CKSZJUBRL5JBP3W6OFVVANCNFSM6AAAAAAWKRRVMU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[maxpatiiuk]

Not showing the save dialog if there actually weren't changes

Ah, that's a separate issue, not connected to record sets.

Two bugs here:

1. When collection object is created, collection relationship is set, which triggers save blocker
2. catalogedDatePrecision is set to 1 by default, which triggers save blocker

[maxpatiiuk]

TODO:

1. Check if the two bugs mentioned in the previous commend (Going to a record set triggers a form change #3259 (comment)) are still reproducible on xml-editor
2. Fix them

[maxpatiiuk]

From @bronwyncombs:

Describe the bug Using the Browse in Forms button in query dialog through stats page requires save before moving pages.

To Reproduce Steps to reproduce the behavior:

1. Go to statistics page
2. Click on a statistic with query attached
3. Click on Browse in Forms
4. Use paginators
5. See error

Expected behavior Should allow to click through forms since no edits are made.

Screenshots
Desktop:

• OS: macOS
• Browser: Chrome
• Specify 7 Version: 7.9-dev

Database Name: If applicable herb_rbge_3_31_23

Reported By Name of your institution

Additional context Database name or any other context about the problem here.

Screen.Recording.2023-07-06.at.6.11.16.PM.mov

[bronwyncombs]

Browse in Forms doesn't have this issue in the main query builder, only through the stats query dialog. Do you still want these merged?

[CarolineDenis]

@maxpatiiuk @melton-jason ,
we met with @bronwyncombs for this issue because I couldn't reproduce. We discovered that it happens only if different tabs in the browser of the stat page are opened. If we have only one time Sp7 opened there is no issue.
What are your thoughts?

[maxpatiiuk]

set a breakpoint on this line:

specify7/specifyweb/frontend/js_src/lib/components/DataModel/resourceApi.js

Line 121 in 39cb18c

this.needsSaved = true;

and when it hits, go up the stack to see who triggered the field change and why

there could be several different causes for this issue - would be best to fix them all

[CarolineDenis]

I cannot reproduce neither on my localhost or on the test panel. I know I saw it happening on Bronwyn's computer..

[grantfitzsimmons]

Browse in Forms doesn't have this issue in the main query builder, only through the stats query dialog. Do you still want these merged?

It looks like this is not the case for me:

https://herbrbge31323-v79-dev.test.specifysystems.org/specify/query/271/

Screen.Recording.2023-07-10.at.11.00.17.AM.mp4

This is likely an unrelated issue that @maxpatiiuk mentioned:

TODO:

1. Check if the two bugs mentioned in the previous commend (Going to a record set triggers a form change #3259 (comment)) are still reproducible on xml-editor
2. Fix them

This has been a problem for a long time (at least since Specify 7.7+) where something is set upon the form loading that makes Specify think some edit has been made when it really has not.

[bronwyncombs]

Still works for me from query builder:

Screen.Recording.2023-07-10.at.11.47.54.AM.mov

Only some have this issue from stats:

screen-recording-2023-07-10-at-113003-am_LLKnihLE.mp4

This is a new instance on a different database with one tab open at a time

[CarolineDenis]

Can we reproduce it on xml?

[grantfitzsimmons]

@bronwyncombs @CarolineDenis

Still works for me from query builder:

Screen.Recording.2023-07-10.at.11.47.54.AM.mov

Only some have this issue from stats:

screen-recording-2023-07-10-at-113003-am_LLKnihLE.mp4

This is a new instance on a different database with one tab open at a time

The issue is that you are testing different queries and different forms. These need to be the same to confirm whether behavior is consistent between them.

On the Preparation form, nothing is being set upon load, which doesn't prompt Specify to ask if you want to save.

On the Determination form, the date precision (presumably) is being set upon load, which prompts Specify to ask you if you want to save before you can navigate away.

This is the actual underlying issue^^^
I'd guess that the issues you're seeing with queries in stats will behave similarly in the query builder, and vice versa.

[CarolineDenis]

Could re-create when:
stats > Paratype > browse in forms
@maxpatiiuk where do we set resource.needSaved to true?

[grantfitzsimmons]

If this is not introduced in v7.9, we should move this to v7.9.1.

[CarolineDenis]

"3.When breakpoint hits, double check that this.specifyModel.name (or this.specifyTable.name if on xml-editor) matches the table name you expect (i.e CollectionObject rather than PickList or TreeDefItem - you might see the later as those are created and edited by front-end behind the scenes, especially on initial page load)"
The name is correct

[CarolineDenis]

@melton-jason can this be closed?

[melton-jason]

I am unsure whether this should be closed or not, as the underlying cause of the issue is very far-reaching and pops up often.

However, this issue has become synonymous with the problem that has been fixed as of #3774, which is why I closed it.
Each instance of this problem can be diagnosed via adding a breakpoint to

specify7/specifyweb/frontend/js_src/lib/components/DataModel/resourceApi.js

Line 121 in 39cb18c

this.needsSaved = true;

However, exactly what caused that line to be run will probably vary for each iteration of the issue, and that may warrant opening separate issues.

This problem as a whole however can probably not be considered entirely 'fixed' until we rewrite the ORM and get away from Backbone.

[bronwyncombs]

Encountered this today on sdnhmpaleo_3_31_23 while using Browse in Forms for Locality records.

Screen.Recording.2023-08-30.at.2.21.46.PM.mov

[grantfitzsimmons]

Solved by #3959

[grantfitzsimmons]

https://dbfordocskufish-v79-dev.test.specifysystems.org/specify/overlay/merge/Agent/?records=1010%2C1028%2C1069%2C1102%2C1514

Screen.Recording.2023-09-13.at.2.06.51.PM.mov

Going through Determination records causes this issue for me in agent merging

[carlosmbe]

Reopened. Still present in Locality Record Sets. Happens in both #3959 and #3774

[carlosmbe]

Screen.Recording.2024-01-08.at.2.10.36.PM.mov