Bug 25911 - Chrome tries to save patron passwords
Summary: Chrome tries to save patron passwords
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 19.11
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-01 19:58 UTC by Christopher Brannon
Modified: 2022-01-20 20:38 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
Bug 29511: Sort hash keys (1.59 KB, patch)
2022-01-20 20:36 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2020-07-01 19:58:45 UTC
If you are like me, you might have your browser try to save passwords for sites.  I like having the browser in my office save some of my passwords.  Logging into Koha is one of them.  However, the problem with this is, every time I save a form that has a password associated with it, it wants to remember this password.  This includes patron records.  This is an annoyance.

Now, my testing has been only with Chrome on this particular issue, and my workaround addresses this to some degree.  So, if there is a more all-encompassing issue to address or solution, feel free to chime in.

I've been able to work around this annoyance by adding the following to jQuery:

$('#pat_memberentrygen #password,#pat_memberentrygen #password2').attr('readonly','').attr('onfocus','$(this).removeAttr("readonly");');

This will make the password fields readonly, which Chrome will ignore.  If you need to edit the field, when you click on it, it will take the readonly attribute away, and it can be edited.  Left as is, when you save, it will, of course, try to save the password.  But it will only do so if the password is edited.  If you leave it untouched, it will not bug you.

I can take this one step further, I add this line to add the readonly attributes before saving.  Then it won't bug me to save the password at all:

$('#pat_memberentrygen #validate').attr('onmouseover', '$("#pat_memberentrygen #password,#pat_memberentrygen #password2").attr("readonly","");');

NOTE: Our Save button has the ID of "validate" because I have some validation code added to the form.  But you get the idea here.  When you hover over the save button, it adds the readonly attribute, and is ignored by the browser.

I don't know if this helps anyone, or gives anyone an idea how to keep patron forms from being a nuisance to staff that save credentials, but I thought I would throw it out here.
Comment 1 Katrin Fischer 2022-01-20 20:36:05 UTC
Created attachment 129676 [details] [review]
Bug 29511: Sort hash keys

This code exists in authorities/authorities.pl and the hash keys are sorted
I just do the same here

To test:
1 - Find/create a record with 245a 245h populated
2 - Load/reload the record several times and note that fields c and b are ordered randomly
3 - Apply patch
4 - Reload and note c and b are ordered alphabetically
5 - Move subfield h before subfield c
6 - Save and reload
7 - Confirm that existing/filled fields retain order in the MARC record

Signed-off-by: Hayley Pelham <hayleypelham@catalyst.net.nz>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 2 Katrin Fischer 2022-01-20 20:38:28 UTC
Comment on attachment 129676 [details] [review]
Bug 29511: Sort hash keys

Bug number typo