Bug 11817 - Staff client next/previous browse JavaScript interferes with other JS functions
Summary: Staff client next/previous browse JavaScript interferes with other JS functions
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
: 12378 (view as bug list)
Depends on: 10404
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-21 19:22 UTC by Owen Leonard
Modified: 2015-06-04 23:23 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2014-02-21 19:22:53 UTC
The JavaScript which builds the staff client detail page's next/previous links uses a selector which is too broad:

Line 79: $('a[href*="biblionumber="]').click(function (ev) 

This can cause problems with other click events on the page. To reproduce the error:

1. Log into Koha as a user who has cataloging permissions.
2. Search for a title.
3. View the detail page for a title which has items attached.
4. From the Edit menu choose "Delete record."

At this point you should see an alert warning you that the title cannot be deleted because it has items attached. However, the page will still proceed to the delete page (and an error message will appear).

The problem doesn't happen if you navigate directly to a detail page.
Comment 1 Fridolin Somers 2014-02-26 14:06:35 UTC
I suggest to remove the browser feature from cataloging module.
It works perfectly for catalogue module, but for cataloging module, I think it can cause too much bugs
Comment 2 Owen Leonard 2014-02-26 14:29:51 UTC
(In reply to Fridolin SOMERS from comment #1)
> I suggest to remove the browser feature from cataloging module.

What do you mean by the cataloging module? Do you mean the staff client? Can you please point out the bugs you know of?
Comment 3 Fridolin Somers 2014-02-26 17:53:47 UTC
(In reply to Owen Leonard from comment #2)
> (In reply to Fridolin SOMERS from comment #1)
> > I suggest to remove the browser feature from cataloging module.
> 
> What do you mean by the cataloging module? Do you mean the staff client? Can
> you please point out the bugs you know of?

No I mean the pages additem and addbiblio, they have been modified by
Comment 4 Fridolin Somers 2014-02-26 17:56:24 UTC
(In reply to Owen Leonard from comment #2)
> (In reply to Fridolin SOMERS from comment #1)
> > I suggest to remove the browser feature from cataloging module.
> 
> What do you mean by the cataloging module? Do you mean the staff client? Can
> you please point out the bugs you know of?

No I mean the pages additem and addbiblio, they have been modified by Bug 10404.
And it is for them that this code exists :
  $('a[href*="biblionumber="]').click(function (ev) 

If only catalogue module is used, we could change this code to :
  $('a[href*="detail.pl?biblionumber="]').click(function (ev)

By the way, addbiblio has been changed but the browser does not appear in page.
Comment 5 Owen Leonard 2014-02-26 20:34:00 UTC
According to Jared the addbiblio and additem pages are modified for two cases:

- Search for a title -> View a title -> Edit that title -> Save the record -> 
  Redirected to title view: Next/previous links are still present

- Search for a title -> View a title -> Edit items -> Next/previous links
  are visible on the edit item screen.

The only bug that I see here is that the "return to results" link from the item edit screen isn't working for me. Fridolin are there other bugs you see? You must be seeing serious problems if you're recommending that the feature be removed.
Comment 6 Fridolin Somers 2014-05-15 09:10:49 UTC
(In reply to Owen Leonard from comment #5)
> The only bug that I see here is that the "return to results" link from the
> item edit screen isn't working for me.
The most important problem is the deletion of a record you reported in first comment. It's a big problem no ?
Comment 7 Gaetan Boisson 2014-06-17 14:34:24 UTC
When one clicks on "delete record", if the record has items attached, the javascript alert is displayed very briefly, then skipped, and Koha proceeds to the deletebiblio page.
The record will not be deleted but we end up with a disgraceful full page message:

ERROR when DELETING BIBLIO 433 : This Biblio has items attached, please delete them first before deleting this biblio

While there doesn't seem to be a risk of accidentally deleting data, it would be good to fix this behaviour.
Comment 8 Gaetan Boisson 2014-06-17 15:44:16 UTC
I spoke a little too fast here : this seems to be fixed in master. But i also can't see the link back to results right now, so this might be linked.
Comment 9 Jonathan Druart 2014-11-04 10:04:39 UTC
Is this problem still exist on master?
It seems that bug 11821 corrected it.
Comment 10 Jonathan Druart 2014-11-04 10:05:31 UTC
*** Bug 12378 has been marked as a duplicate of this bug. ***
Comment 11 Owen Leonard 2014-11-11 17:30:06 UTC
I agree with Jonathan -- Bug 11821 seems to have fixed this bug.