Bug 19591 - Saving a system preference jumps to main page
Summary: Saving a system preference jumps to main page
Status: RESOLVED DUPLICATE of bug 20504
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: 16.11
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-08 09:29 UTC by Christian Stelzenmüller
Modified: 2018-03-31 07:20 UTC (History)
2 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Stelzenmüller 2017-11-08 09:29:32 UTC 
I don't know if this was intended or not.

When saving a system preference, it jumps to the main page of the category, instead of staying on the searched system preference, like in 3.22.

Test:
1. Search a system preference, i. e. Opaccredits.
2. Change something.
3. Save it.
4. It jumps to the "category subpage" on the left side.
Comment 1 Owen Leonard 2017-11-09 16:28:57 UTC 
When you save a system preference the page shouldn't refresh at all. The change happens behind the scenes and a message should pop up briefly indicating success.

If you find that clicking the save button redirects the page, you might have a JavaScript error somewhere. Do you have something in the IntranetUserJS system preference?
Comment 2 Christian Stelzenmüller 2017-11-10 16:12:50 UTC 
(In reply to Owen Leonard from comment #1)
> When you save a system preference the page shouldn't refresh at all. The
> change happens behind the scenes and a message should pop up briefly
> indicating success.
> 
> If you find that clicking the save button redirects the page, you might have
> a JavaScript error somewhere. Do you have something in the IntranetUserJS
> system preference?

There is indeed a js error:
"Error: Syntax error, unrecognized expression: .transl."

Maybe it's that. I'll ask Katrin on Monday, thanks :-)
Comment 3 Josef Moravec 2017-11-11 09:26:50 UTC 
I tried on master and it works for me. Do you use some other language then english? Or do you have something in intranetuserjs preference?
Comment 4 Christian Stelzenmüller 2017-11-14 13:58:57 UTC 
Yes, it's Intranetuserjs.

It must be something in these parts:

var currlang = $('html').attr('lang');
$(".transl").hide();
$(".transl." + currlang).show();

if (currlang == 'en' || currlang == 'en-GB') {
$("span.results_summary span.de-DE").hide();
} else {
$("span.results_summary span.en").hide();
}

Thanks for the help!
Comment 5 Christian Stelzenmüller 2017-11-14 14:19:13 UTC 
It's the second dot in ".transl."

In 16.11 it's causing that error
Comment 6 Josef Moravec 2017-11-14 14:22:34 UTC 
(In reply to Christian Stelzenmüller from comment #4)
> Yes, it's Intranetuserjs.
> 
> It must be something in these parts:
> 
> var currlang = $('html').attr('lang');
> $(".transl").hide();
> $(".transl." + currlang).show();
> 
> if (currlang == 'en' || currlang == 'en-GB') {
> $("span.results_summary span.de-DE").hide();
> } else {
> $("span.results_summary span.en").hide();
> }
> 
> Thanks for the help!


So I am closing this bug.
Comment 7 Christian Stelzenmüller 2017-11-15 09:55:07 UTC 
Now we found the exact cause:

The language in the html from the system preference page ist missing:

<html lang="">

Therefore the js regarding the language caused this error.
Comment 8 Katrin Fischer 2018-03-31 07:20:13 UTC 
I've filed a new bug to explain the problem behind the error we have seen.

*** This bug has been marked as a duplicate of bug 20504 ***