Summary: | Remove username and cardnumber from default value form in patron import | ||
---|---|---|---|
Product: | Koha | Reporter: | Elaine Bradtke <eb> |
Component: | Patrons | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | daniel.gaghan, eb, gmcharlt, jonathan.druart, kyle.m.hall |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
Description
Elaine Bradtke
2020-06-02 18:52:15 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? 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) (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. 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. 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. 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 Hi Elaine, is userid listed in your BorrowerMandatoryFields system preference by chance? (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. 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. (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. 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. 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. 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. |