https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42295 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #43 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Victor Grousset/tuxayo from comment #38)
Comment on attachment 202758 [details] [review] Bug 42295: Tidy all script tags - staff includes
Review of attachment 202758 [details] [review]: -----------------------------------------------------------------
::: koha-tmpl/intranet-tmpl/prog/en/includes/cateditor-ui.inc @@ +66,4 @@
config: { resources: { + marcflavour: Koha.prefs.marcflavour, + themelang,
Shouldn't it be this instead? themelang: themelang,
It's the same, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/... (In reply to Victor Grousset/tuxayo from comment #39)
Comment on attachment 202758 [details] [review] Bug 42295: Tidy all script tags - staff includes
Review of attachment 202758 [details] [review]: -----------------------------------------------------------------
::: koha-tmpl/intranet-tmpl/prog/en/includes/cateditor-ui.inc @@ +42,5 @@
+ + const interface = "[% interface | html %]"; + const themelang = "[% themelang | html %]"; + const lang = "[% lang | html %]"; + const logged_in_user_borrowernumber = "[% logged_in_user.borrowernumber | html %]";
So this will replace using [% logged_in_user.borrowernumber | html %] without quotes.
This variable that has quotes for the data initializing it.
Before, from what I understand, it was a Koha::Patron object so borrowernumber would be an int.
Then it means here we change to having the borrowernumber as a string instead of an int. Is this a planned change and does the consumers of logged_in_user_borrowernumber don't care about having an int vs that same int converted to a string? Or maybe the html filter was already converting the int to a string? And the quotes here are just redundant and change nothing so it's not a problem.
Certainly an unintended change, but conservative: the assignment won't generate a JS error if logged_in_user.borrowernumber is not set (which should obviously never happen anyway). The var is used to save pref's value (is a string in DB), or to create a new macro (patron_id is int, but will be stringified), it shouldn't be a problem. (In reply to Victor Grousset/tuxayo from comment #40)
var CAN_user_parameters_manage_column_config = [% CAN_user_parameters_manage_column_config ? 1 : 0 | $raw %];
Is there a reason to use the $raw filter here vs the $html filter in the other permissions? (or vice versa)
No, we should use $raw when we know it's 1 or 0. We are not consistent in other places and there are no strict rule.
There are still 3 occurrences of defaultPatronSearchFields which isn't defined anymore. (2 in code, 1 in commen) And it's successor, Koha.permissions.DefaultPatronSearchFields isn't used.
Same with defaultPatronSearchMethod extendedPatronAttributes showPatronFirstnameIfDifferentThanPreferredname
Oops, good catch. See patch "Use vars stored in Koha.prefs" -- You are receiving this mail because: You are watching all bug changes.