Bug 25657 - Remove username and cardnumber from default value form in patron import
Summary: Remove username and cardnumber from default value form in patron import
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-02 18:52 UTC by Elaine Bradtke
Modified: 2023-12-10 10:04 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elaine Bradtke 2020-06-02 18:52:15 UTC
Somewhere in a recent upgrade, the userid became a required field for importing patrons.  If it is not present Koha will attempt to use the userid from the person logged in for all userids.  This causes the import to fail as they're 'duplicate'.  This is an easy fix - update the notes to state the userid is a required field.
Comment 1 Jonathan Druart 2020-06-03 08:28:41 UTC
Hi Elaine,

I have tried on 19.11.06, I am not sure I understand what the problem is.
If I use the import patron tool to create new patrons and the csv file does not contain a userid (either no value in the cell, or no header at all), then the userid is automatically built concatenating firstname and surname.

Can you detail a bit more?
Comment 2 Elaine Bradtke 2020-06-03 17:32:40 UTC
This happened in 19.11.05.   I upload and overwrite the patron data on a quarterly basis (it's derived from a spreadsheet of membership data). 
The error message I got was:
"Userid elaine.bradtke is already used by another patron" repeated for all 2000+ records.  I went back to the spreadsheet, gave everyone arbitrary userids and it worked.
Just to test this wasn't a fluke, I've gone back to the spreadsheet, removed the userid column and tried the upload again.  It failed:
 mport results :
0 imported records
0 overwritten
0 not imported because already in borrowers table and overwrite disabled
2124 not imported because they are not in the expected format
2124 records parsed
Back to Tools


Feedback:
headerrow : cardnumber, title, firstname, surname, address, address2, city, state, zipcode, country, dateexpiry, email, phone, branchcode, categorycode,
Content-Disposition : form-data; name="uploadborrowers"; filename="EFDSS - Membership Export 2020-06-02.csv"
Content-Type : application/octet-stream
Parsing upload file EFDSS - Membership Export 2020-06-02.csv


Error analysis:
Userid elaine.bradtke is already used by another patron. (repeated 2000+ times)
Comment 3 Elaine Bradtke 2020-06-03 18:24:45 UTC
(In reply to Jonathan Druart from comment #1)
> Hi Elaine,
> 
> I have tried on 19.11.06, I am not sure I understand what the problem is.
> If I use the import patron tool to create new patrons and the csv file does
> not contain a userid (either no value in the cell, or no header at all),
> then the userid is automatically built concatenating firstname and surname.
> 
> Can you detail a bit more?

Are you saying it would work if there was a column userid, but no data in it?
We've never had a userid field empty or not, in previous imports and it worked.
Comment 4 Jonathan Druart 2020-06-04 09:40:23 UTC
Yes, I have tried with:
 * "userid" header and no data in it
 * no userid header

In both cases the import succeeded, and the patrons had a userid=firstname.surname

Could you create a new patron with a given userid, login with it, then use a simple version of the CSV file?
If you can recreate the problem (on a sandbox for intance), share the CSV sample file and I will investigate what's going on.
Comment 5 Elaine Bradtke 2020-06-04 19:24:43 UTC
We have two instances of Koha, they are supposed to be identical (one test, one production) I always do large imports in test first.  The problem seems to be in the test site, I just successfully imported into production the same patron data that failed in test.  I'll have a word with our tech person as to what differences there are, aside from being on two different cloud servers.
Comment 6 Elaine Bradtke 2020-06-05 18:46:00 UTC
We're using two different versions of the OS - 
The production system where the import works:
Linux library.efdss.org 3.16.0-4-amd64 #1 SMP Debian 3.16.51-2 (2017-12-03) x86_64 
The test system - where the import fails is running: 	Linux public 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64
Comment 7 Katrin Fischer 2020-06-06 13:29:17 UTC
Hi Elaine, is userid listed in your BorrowerMandatoryFields system preference by chance?
Comment 8 Elaine Bradtke 2020-06-08 17:12:43 UTC
(In reply to Katrin Fischer from comment #7)
> Hi Elaine, is userid listed in your BorrowerMandatoryFields system
> preference by chance?

surname|cardnumber  is all we have - in both production and test sites.
Comment 9 Daniel Gaghan 2020-07-17 16:53:45 UTC
We are seeing this issue too, borrowernumber wasn't required before 19.11 so this is a new bug. PCCLD is definitely in favor of not requiring borrowernumber in a patron import.
Comment 10 Katrin Fischer 2020-07-18 13:07:54 UTC
(In reply to Daniel Gaghan from comment #9)
> We are seeing this issue too, borrowernumber wasn't required before 19.11 so
> this is a new bug. PCCLD is definitely in favor of not requiring
> borrowernumber in a patron import.

Hi Daniel, I think it might be good to file a separate bug for the borrowernumber as this was about the userid and link them together. I agree the borrowernumber should not be mandatory.
Comment 11 Katrin Fischer 2020-07-18 13:12:50 UTC
I have tested creating and overlaying patrons on master, with a file with 2 patrons and a header file of:

cardnumber,surname,firstname,branchcode,categorycode

All worked well. I think we need to narrow this down some more if it only appears in older versions, differences in the files etc.
Comment 12 Elaine Bradtke 2021-05-13 20:05:56 UTC
I've found the answer as to what is happening.

It has to do with default values.  We ignore this option when uploading patron records.  However, the password auto-fill in Chrome doesn't.  It filled in my staff-login information as a default entry.  Then the import failed because this was duplicated for every record, and already in use.

Since userid is supposed to be unique, I would argue that having this as a default value is a recipe for failure.  Regardless of the auto-fill problem, if I were to enter a default value in this field, it wouldn't be unique.
Comment 13 Katrin Fischer 2022-10-02 11:53:39 UTC
Hi Elaine, thx for not giving up investigating here. I agree that userid/username does not really make sense on this form. I have changed the bug description accordingly.