Bug 19591

Summary:	Saving a system preference jumps to main page
Product:	Koha	Reporter:	Christian Stelzenmüller <christian.stelzenmueller>
Component:	System Administration	Assignee:	Bugs List <koha-bugs>
Status:	RESOLVED DUPLICATE	QA Contact:	Testopia <testopia>
Severity:	enhancement
Priority:	P5 - low	CC:	gmcharlt, josef.moravec
Version:	16.11
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

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 ***