https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42295
Jonathan Druart <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #43 from Jonathan Druart <[email protected]> --- (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/Object_initializer (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. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
