Bug 2237 - Use primary email address as Koha login account
Summary: Use primary email address as Koha login account
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Target Milestone: ---
Assignee: Bugs List
QA Contact:
URL:
Whiteboard:
Keywords:
: 17769 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-11 07:38 UTC by Chris Cormack
Modified: 2019-05-06 05:28 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
AutoAddUserid syspref example (21.99 KB, image/png)
2008-06-11 07:41 UTC, Chris Cormack
Details
AutoAddPassword syspref example (20.85 KB, image/png)
2008-06-11 07:42 UTC, Chris Cormack
Details
example of 'email' src field populating 'userid' field, and 'password' field populated with random value (31.80 KB, image/png)
2008-06-11 07:48 UTC, Chris Cormack
Details
Adding a jscript button to generate a new random password, but only if 'staffaccess' user-perm is on (38.53 KB, image/png)
2008-06-13 09:01 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:48:08 UTC


---- Reported by mason@kohaaloha.com 2008-06-11 07:38:58 ----

The idea of this feature is to allow userid and password be populated automatically from other fields, when adding a new user.

this has a few other benefits

1) in combination with user-permissions locks userid and password fields from manually being changed
2) populates password field with randomly generated passwords

the feature currently uses the jscript onkeyup() function to update the destination fields character by character - when the source field is changed



---- Additional Comments From mason@kohaaloha.com 2008-06-11 07:41:22 ----

Created an attachment
AutoAddUserid syspref example





---- Additional Comments From mason@kohaaloha.com 2008-06-11 07:42:03 ----

Created an attachment
AutoAddPassword syspref example





---- Additional Comments From mason@kohaaloha.com 2008-06-11 07:48:12 ----

Created an attachment
example of 'email' src field populating 'userid' field, and 'password' field populated with random value





---- Additional Comments From mason@kohaaloha.com 2008-06-11 20:03:17 ----

Hi Joe

On 2008/06/12, at 7:17 AM, Joe Atzberger wrote:

Mason --

There are a handful of problems I see with this patch.
Uses EXPR in a way guaranteed to create multiple warnings unless both of these new features are ON.
Good call, i didn't consider the log warnings here,  i will fix this
Uses EXPR at all.
Hmm, i dont understand your point here, is *any* EXPR usage bad, or just unneeded EXPR usage?

I'm sure i *could* rewrite this mod to not use EXPR tags, but the template would be much more confusing than using EXPR tags. 
And i would need to introduce 8-ish? new TMPL_VARS to the script if i removed the EXPR tags, is that a better solution??
Or do you know a better way still to achieve this?

Did i use an unneeded EXPR tag, instead of a VAR tag?

Adds meaninglessness (e.g. "home111", "email33") to labels.
Sure, late-night last minute typo there, i will fix this

Changes sort order of branches to be by code instead of the name that actually displays.  I.E., allows apparent disorder in display.

Good spotting, i did seem to miss Ryan's recent branch-sort commit there

 -for my $branch (sort { $branches->{$a}->{branchname} cmp $branches->{$b}->{branchname} } keys %$branches) {                                              
+foreach my $branch (sort keys %$branches) {   


Uses onkeyup instead of something more logical.  (Not every keypress changes value.)
Sorry - my jscript isnt that hot, so i welcome a better way to do this, 
any suggestions for a better jscript function/solution? 

FYI: There are many examples of onkeyup() being used in this fashion, so it seems to be a commonly used/accepted solution?
-> http://www.w3schools.com/jsref/jsref_onkeyup.asp

The whole idea of the proposed CAN_user_nonstaffaccess, as I interpret it, is to block updates to nonstaff accounts unless the permission is granted to the operator.  Is that the intent?  I don't understand the rationale for doing it this way, since the user should probably not be allowed to memberentry at all in that case.  

Is there really a need to allow, for example, CAN_user_staffaccess but NOT CAN_user_nonstaffaccess?

There might be..
But there *is* a need to disallow access to *all* category_types, which was the goal of this additional user-perm.
I realise there are a few ways to achieve this too..

One way would be to change the existing 'staff_access' perm to handle all cat_types, not just staff - (the perm would need to be renamed too)
I think this is the best idea, but some people might not like that the 'staffaccess' user-perm's behavior is changed, 
i dont yet know, so i didnt want to fiddle with it.

So adding a new user-perm was the less invasive initial commit. rather than the best commit

But if people agree, changing the existing staffaccess user-perm to allow/disallow *all* cat-types, and updating its name to reflect the new behavior would be the best solution ( 'editlogins' perhaps?)

Any comments on this last point peoples?

Thanks for checking my patch Joe, You did spot a few things that i overlooked.

Mason




---- Additional Comments From mason@kohaaloha.com 2008-06-13 09:01:41 ----

Created an attachment
Adding a jscript button to generate a new random password, but only if 'staffaccess' user-perm is on





---- Additional Comments From nengard@gmail.com 2009-12-17 00:52:15 ----

I need a clarification about this.  Does this mean that you have to add those preferences to local use and set them the way you're suggesting? or are these system preference supposed to be there for all?



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:48 UTC  ---

This bug was previously known as _bug_ 2237 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2237
Imported an attachment (id=578)
Imported an attachment (id=579)
Imported an attachment (id=580)
Imported an attachment (id=581)

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was mason@kohaaloha.com.
CC member arm@hanover.ca does not have an account here
The original submitter of attachment 578 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 579 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 580 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 581 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Jeremy Evans 2014-10-31 11:03:57 UTC
We would like the userId to automatically pick up the email address as a default value.
Comment 2 Marcel de Rooy 2014-10-31 13:04:15 UTC
(In reply to Jeremy Evans from comment #1)
> We would like the userId to automatically pick up the email address as a
> default value.

Hi Jeremy,
I have been/am working on some reports recently touching this area in some way. (I want to receive a notice when changing login details for instance.) See bug 13096. (work in progress)

I change the title of this (old) report to make it more specific. My idea would be to add a pref that connects the primary email field to the userid, and disable the userid field. A change to primary email would be propagated to userid.

Note that Koha already supports an auto-password function.
Comment 3 Jeremy Evans 2014-10-31 14:02:40 UTC
Thanks for your quick reply - yes that makes sense and will improve the user records, preventing the email address appearing in multiple places.  (e.g. email, userId etc)
It also helps to reduce the number of fields required to create a user record - e.g. at the desk while a new patron is waiting to checkout a book.
Jeremy
Comment 4 Christopher Brannon 2016-10-09 00:21:20 UTC
Many families utilize the same e-mail address for more than one library card.  What is the solution for this?  Will the single e-mail login prompt you to pick the family member and enter their password?
Comment 5 Marc Véron 2016-10-09 14:02:33 UTC
(In reply to Christopher Brannon from comment #4)
> Many families utilize the same e-mail address for more than one library
> card.  What is the solution for this?  Will the single e-mail login prompt
> you to pick the family member and enter their password?

That is somehow already a problem, see:
Bug 16711 - OPAC Password recovery: Handling if multiple accounts have the same mail address
Comment 6 Christopher Brannon 2016-10-10 14:25:43 UTC
Actually, another approach is to enter the associated library card number along with the userid.

In our consortium, we have our userids match the library card number, not the e-mail address.  I would suggest either use the library card number as the id, making each id unique as it should be, or a choice in setup.  If e-mail address is used, it will introduce either the need for another identifier, or will limit accounts to only one account with a particular e-mail address.
Comment 7 Chris Kirby 2016-12-14 01:56:20 UTC
*** Bug 17769 has been marked as a duplicate of this bug. ***
Comment 8 Katrin Fischer 2019-05-04 17:43:15 UTC
Marcel, do you still plan to work on this?
Comment 9 Marcel de Rooy 2019-05-06 05:28:12 UTC
(In reply to Katrin Fischer from comment #8)
> Marcel, do you still plan to work on this?

I cleared the Assignee field.