Pressing Shift-F3 in the MARC editor results in invalid lose data warning

[Liam Whalen]

 When pressing Shift-F3 in the MARC Editor to bring up a dialog to jump to a record via TCN, the Staff Client presents the user with a message indicating that they will lose data regardless of that state of the MARC record (edited or not).

Evergreen 2.4.0
OpenSRF 2.2.0
PostgreSQL 9.1
Ubuntu 12.04

In the Staff Client

Search -> Search the Catalog
enter a search term and submit the search
click on a record in the search results
Shift-F3
warning message appears when the record has not been edited.

The warning message should only appear when the record has been edited. As well, the warning should appear before the TCN input dialog appears.

[Liam Whalen (whalen-ld)]

I have a fix for this issue. It uses the fix from https://bugs.launchpad.net/evergreen/+bug/971912, and adds a check for the press of the shift button. It also modifies when the prompt for lost data appers.

[Liam Whalen (whalen-ld)]

I am going to work this into master in hopes of having it included in 2.6-rc1.

[Liam Whalen (whalen-ld)]

This fix works in concert with https://bugs.launchpad.net/evergreen/+bug/1282277

[Liam Whalen (whalen-ld)]

I have merged my changes into master. They can be found here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_MARC_EDIT_SAVE_AND_TCN_SEARCH

[Kyle Tomita (tomitakyle)]

An issue with prompt showing from new tab:
1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Cancel on prompt
5) Open a new tab
6) Pressed Shift-F3 and got prompt, "This action may cause you to lose unsaved information in the current interface. Continue anyway?"
Expected to not get the prompt.

An issue with pressing cancel on prompt and TCN still showing:
1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Ok on prompt
5) Actions for this Record -> MARC edit
6) Shift-F3 brings up unsaved data prompt
7) Pressed Cancel
8) TCN prompt comes up
Expected to not get the TCN prompt.

[Liam Whalen (whalen-ld)]

This took a lot longer to fix than I anticipated. I found some other errors that had to do with closing the window or the program while changes were in effect. In some cases it was not warning that changes may be lost, and in others it was warning them that changes might be lost when there were no changes.

The Shift-F3 issues reported have been fixed.

As well, if you modify a MARC record then go to OPAC view, if you attempt to close the window, you will be prompted that you may lose data. I opted to keep this warning because the user can return to the MARC editor to save the data. This will allow cataloguers to return to the OPAC view to look at other parts of the record without having to worry that they may lose their changes if they attempt to close the window by accident.

Here is the updated branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_MARC_EDIT_SAVE_AND_TCN_SEARCH

[Kyle Tomita (tomitakyle)]

Everything looks good except in the following workflow:

1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Ok on prompt
5) Close the tab/Press Shift-F3
6) No prompt is given and the tab closes/TCN prompt is brought up
Expected to get a prompt.
This contradicts part of your last comment,
"As well, if you modify a MARC record then go to OPAC view, if you attempt to close the window, you will be prompted that you may lose data."

I am not sure if this is related since it is a reload of the record:
1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Ok on prompt
5) Actions for this Record -> MARC edit
6) Press Shift-F8, to reload the record
7) Record is reloaded
Expected to get a prompt

[Liam Whalen (whalen-ld)]

Thank you for the great testing! I will fix these tomorrow. Now that things are done per tab instead of per window, I do not expect this time to take as long. Do you operate with MARC edit as your default screen when you test?

Liam

> On Mar 11, 2014, at 5:33 PM, Kyle Tomita <email address hidden> wrote:
>
> Everything looks good except in the following workflow:
>
> 1) Load a record from Shift-F3
> 2) From marc edit screen modify a field
> 3) Actions for this Record -> OPAC View
> 4) Select Ok on prompt
> 5) Close the tab/Press Shift-F3
> 6) No prompt is given and the tab closes/TCN prompt is brought up
> Expected to get a prompt.
> This contradicts part of your last comment,
> "As well, if you modify a MARC record then go to OPAC view, if you attempt to close the window, you will be prompted that you may lose data."
>
>
> I am not sure if this is related since it is a reload of the record:
> 1) Load a record from Shift-F3
> 2) From marc edit screen modify a field
> 3) Actions for this Record -> OPAC View
> 4) Select Ok on prompt
> 5) Actions for this Record -> MARC edit
> 6) Press Shift-F8, to reload the record
> 7) Record is reloaded
> Expected to get a prompt
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1282286
>
> Title:
> Pressing Shift-F3 in the MARC editor results in invalid lose data
> warning
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> When pressing Shift-F3 in the MARC Editor to bring up a dialog to
> jump to a record via TCN, the Staff Client presents the user with a
> message indicating that they will lose data regardless of that state
> of the MARC record (edited or not).
>
> Evergreen 2.4.0
> OpenSRF 2.2.0
> PostgreSQL 9.1
> Ubuntu 12.04
>
> In the Staff Client
>
> Search -> Search the Catalog
> enter a search term and submit the search
> click on a record in the search results
> Shift-F3
> warning message appears when the record has not been edited.
>
> The warning message should only appear when the record has been
> edited. As well, the warning should appear before the TCN input
> dialog appears.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1282286/+subscriptions

[Kyle Tomita (tomitakyle)]

MARC edit was my main screen to modify records for testing. Can you suggest another screen to edit from? I am willing to test more use cases.

[Liam Whalen (whalen-ld)]

I mean, is your staff client set up to use the MARC edit as the default pane? As opposed to opening up to the OPAC view.

Liam

> On Mar 12, 2014, at 9:10 AM, Kyle Tomita <email address hidden> wrote:
>
> MARC edit was my main screen to modify records for testing. Can you
> suggest another screen to edit from? I am willing to test more use
> cases.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1282286
>
> Title:
> Pressing Shift-F3 in the MARC editor results in invalid lose data
> warning
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> When pressing Shift-F3 in the MARC Editor to bring up a dialog to
> jump to a record via TCN, the Staff Client presents the user with a
> message indicating that they will lose data regardless of that state
> of the MARC record (edited or not).
>
> Evergreen 2.4.0
> OpenSRF 2.2.0
> PostgreSQL 9.1
> Ubuntu 12.04
>
> In the Staff Client
>
> Search -> Search the Catalog
> enter a search term and submit the search
> click on a record in the search results
> Shift-F3
> warning message appears when the record has not been edited.
>
> The warning message should only appear when the record has been
> edited. As well, the warning should appear before the TCN input
> dialog appears.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1282286/+subscriptions

[Kyle Tomita (tomitakyle)]

Default pane is opac view

[Liam Whalen (whalen-ld)]

I have a new commit ready. The code now uses the current Staff Client's locking mechanisms, but when it returns to the MARC edit screen, if changes are still present, then it relocks the tab. This should allow previous functionality like the reloading a record via Shift-F8 to still prompt for loss of data.

Let me know if you find any more bugs.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_MARC_EDIT_SAVE_AND_TCN_SEARCH

[Kyle Tomita (tomitakyle)]

1) Load record A from Shift-F3
2) From marc edit screen modify a field
3) Shift-F3
4) Select Ok on prompt
5) Enter TCN of Record B
5) Actions for this Record -> MARC edit (don't modify anything)
6) Actions for this Record -> Opac View or close tab
7) Receive prompt for lost data
Expected to switch view to OPAC or have the tab close

NOTE: If step 6 is Shift-F3, TCN prompt only shows up.

[Liam Whalen (whalen-ld)]

This is now fixed with a commit pushed to

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_MARC_EDIT_SAVE_AND_TCN_SEARCH

As well, I changed my mind about how the Staff Client should work when closing a window or leaving the current record when not in the MARC editor. Previously, I thought it would be a good idea to prompt for data lose even when not in the MARC editor, but this is not how the client currently works, and the user does have to click a message to let them know they may lose data when they leave the MARC editor, so the commit no longer prompts for warnings when the user tires to leave a tab, close a window, or exit the Staff Client when they are not in the MARC editor.

[Kyle Tomita (tomitakyle)]

Pulled in commit and signedoff on this branch, http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ktomita/lp1282277_lp1282286-signoff

Good job Liam on fixing everything I found.

[Liam Whalen (whalen-ld)]

This fix as is has an error that stops the copy editor from working.

Here is the commit that fixes that:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_MARC_edit_TCN_warning

Liam

[Liam Whalen (whalen-ld)]

There is an bug in this code that cause duplicate records to be created when performing Cataloguing -> Create New MARC Record. It also creates a UI bug when importing via Cataloguing -> Import Record from Z39.50.

I am working on fixing this.

[Liam Whalen (whalen-ld)]

Here is the fix for the bug that creates Duplicate bibs and an error with the z39.50 UI.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_MARC_edit_TCN_warning

Liam

[Liam Whalen (whalen-ld)]

The above fix was not signed off on. Here is the fix for duplicate bibs with a sign-off:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282277_LP1282286_Double_Bib_Error

[Yamil (ysuarez)]

Good news and bad news, I did some testing for bug squashing day and all of the tests passed (see below). Regretfully the code changes break the authority MARC editor. My early hunch without looking at the code, is that it might be related to the fact that the auth MARC editor lives in a floating window and not in a tab.

Here are the two main ways to bring up the authority MARC editor, which also trigger the error.

From bib MARC editor:
1) start from the MARC edit view
2) right click an authority controlled bib tag (for example bib tags: 1xx, 7xx, 6xx)
3) Select "Create new authority form this field -> Create and edit"
4) Error that is shown: FIXME: MARC Editor, loadRecord: TypeError: tabs is null
5) after clicking OK the floating auth MARC editor is show, but only showing the empty fixed fields (that should be pre-filled in) and not lower part with the non-fixed fields tags showing.
NOTE: that the expected auth data can be seen by clicking not he "flattest editor"

From the Manage Authorities screen (reachable format he Cataloging menu)
1) search for an authority by providing a search string and an auth type
2) click on the "Actions" button and select "edit"

3) Error that is shown: FIXME: MARC Editor, loadRecord: TypeError: tabs is null
4) after clicking OK the floating auth MARC editor is show, but only showing the empty fixed fields (that should be pre-filled in) and not lower part with the non-fixed fields tags showing.
NOTE: that the expected auth data can be seen by clicking not he "flattest editor"

-------- tests that passed ----

test 1) passed

Search -> Search the Catalog
enter a search term and submit the search
click on a record in the search results
Shift-F3
warning message appears when the record has not been edited.

test 2) passed with + tab; ctrl-t

An issue with prompt showing from new tab:
1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Cancel on prompt
5) Open a new tab
6) Pressed Shift-F3 and got prompt, "This action may cause you to lose unsaved information in the current interface. Continue anyway?"
Expected to not get the prompt.

test 3) passed

An issue with pressing cancel on prompt and TCN still showing:
1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Ok on prompt
5) Actions for this Record -> MARC edit
6) Shift-F3 brings up unsaved data prompt
7) Pressed Cancel
8) TCN prompt comes up
Expected to not get the TCN prompt.

test 4) occurs in the same way; might not be buggy behavior

1) Load a record from Shift-F3
2) From marc edit screen modify a field
3) Actions for this Record -> OPAC View
4) Select Ok on prompt
5) Close the tab/Press Shift-F3
6) No prompt is given and the tab closes/TCN prompt is brought up
Expected to get a prompt.
This contradicts part of your last comment,
"As well, if you modify a MARC record then go to OPAC view, if you attempt to close the window, you will be prompted that you may lose data."

test 5) passed: prompt shown

I am not sure if this is related since it is a reload of the record:
1) Load a record from Shift-F3
2) From marc ...

[Liam Whalen (whalen-ld)]

Yamil,

I am sorry I missed you today. This fix works together with my Marc Editor no saved data warning fix. The patch located here, fixes all the null tab errors.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/Unintialized_Vars_Fix

I am still working out how to best setup my patches when the reach across multiple bugs. I would like to include all necessary code in each patch, but then the different branches would conflict with each other. What I should probably do, is only post commits to a single LP, and link the others to that LP.

LIam

[Jennifer Pringle (jpringle-u)]

Tested all situations listed in this ticket as well as creating new MARC records, copy editor, Z39.50, and creating and editing authorities and all work as expected.

[Jennifer Pringle (jpringle-u)]

I have tested this code and consent to signing off on it with my name, [Jennifer Pringle] and my email address, [ <email address hidden> ].

[Ben Shum (bshum)]

Picked commits with Jennifer's signoff to master. Doing a little more testing before backporting to supported release series.

[Ben Shum (bshum)]

Changing milestone to reflect real target of 2.8 series - 2.8 beta, here we come!

[Jason Stephenson (jstephenson)]

Looks like this breaks editing pre-imported records in Vandelay.

I was testing fixes for 957466 and if I try to edit an incoming record in my queue, I get a JavaScript application error dialog saying:

TypeError: tab is undefined

after every key press.

[Dan Wells (dbw2)]

I experienced the exact same thing as Jason when editing a serial MFHD record. Reopening this bug as incomplete.

[Liam Whalen (whalen-ld)]

I have a fix for this error and another error that occurs when loading a MARC record. It can be found in my working branch here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282296_Tab_Is_Null_Error

Liam

[Jason Stephenson (jstephenson)]

Liam's fix works for my problem, but I think Dan Wells should have a look, too, before this gets pushed.

I also never saw an error when loading a MARC record before Liam's latest branch, so I'm not sure what circumstances lead to that.

Liam, you might want to sign off on your commit. I noticed it was missing when I went to add a sign off of my own.

[Liam Whalen (whalen-ld)]

Jason, thank you for reminding me about the sign off. Here is the branch with my sign off.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/ldw/LP1282296_Tab_Is_Null_Error

Liam

[Jason Stephenson (jstephenson)]

Liam, thanks for adding the sign-off. I still think Dan Wells ought to have a look to verify that the latest change resolves his MFHD problem.

I added my sign-off and pushed to collab/dyrcona/LP12822286_Tab_is_NULL_error in the working repository:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/LP12822286_Tab_is_NULL_error

[Jason Stephenson (jstephenson)]

Heh. Liam transposed an 8 to a 9 in his branch and I added a 2 when I tried to "fix" it in my branch name.

[Dan Wells (dbw2)]

Looks right to me. Pushed; thanks, all!

[Dan Wells (dbw2)]

To clarify, I pushed the fix commit to master. As far as I can tell, nothing in the bug has been backported yet. Ben, you mentioned doing some more testing before backporting. Is that still something in progress?

[Ben Shum (bshum)]

Hi Dan, no I haven't had a chance to look at this further in previous versions of Evergreen. If you think it's safe to backport, I'll leave it at your discretion, but I'm also fine with saying "upgrade to 2.8 for the best experience"