Bug 9484 - userid not generated consistently (different editing pages)
Summary: userid not generated consistently (different editing pages)
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Target Milestone: ---
Assignee: Adrien SAURAT
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-24 16:05 UTC by Adrien SAURAT
Modified: 2014-05-26 21:04 UTC (History)
5 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
proposed patch (1.94 KB, patch)
2013-01-24 16:14 UTC, Adrien SAURAT
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 9484: userid not generated consistently (different editing pages) (2.60 KB, patch)
2013-02-16 17:01 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 9484: userid not generated consistently (different editing pages) (2.68 KB, patch)
2013-03-26 14:53 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Adrien SAURAT 2013-01-24 16:05:40 UTC
Different accesses to the memberentry.pl generate different behaviors when it comes to generate a new userid.

When creating a new patron or modifying the full page of a patron, if the userid input zone is left empty, a userid like "firstname.surname" will be generated.

But when accessing the editing page through the "Details"/"Library Details" tab, only a section of the editing page is displayed. The firstname and surname input boxes are not present, but the perl code assume that they are.
In this case, if you empty the userid box, the perl script will try to generate a new id but "firstname" and "surname" will be empty. You end up with a simple dot as a login.
When these input boxes are not present, the firstname and surname stored in the database should be used instead.
Comment 1 Adrien SAURAT 2013-01-24 16:14:07 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2013-01-25 14:37:00 UTC
Could you add a test plan to your commit message? Specifically what operations we should test--new patrons, patron edits, etc?
Comment 3 Bernardo Gonzalez Kriegel 2013-02-16 17:01:37 UTC Comment hidden (obsolete)
Comment 4 Marcel de Rooy 2013-03-26 14:52:26 UTC
QA Comments:
Compliments for Bernardo. Adding a test plan and running koha-qa when signing off is really great!
Clearing userid via the Library details route does not work anymore. This was actually a bug. So, no worries.
Question if it should be possible to have no userid/password seems to be out of scope here.

Looks good to me.
Comment 5 Marcel de Rooy 2013-03-26 14:53:31 UTC
Created attachment 16895 [details] [review]
Bug 9484: userid not generated consistently (different editing pages)

When modifying a patron through different pages, the userid
generation does not behave always the same way; this patch
corrects this:
- when firstname and surname are present in the form, they
are used for the generation;
- if there are not in the form, the firstname and surname
in database are used instead.

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>

Comment: Work as described. No errors.
Test
This patch lacks a test plan, so I do the following
1) New user, empty userid, autocompleted
2) Edit user, change userid, saved correctly
3) Edit user, main edit window, emptied userid, autocompleted
4) Edit user, Detail > Library use, emptied userid, not autocomplete (not even a dot)
5) Applied patch
6) Repeated 1-3, same behavior
7) Repeated 4), now autocompletes with same userid as 3)

So, works as described.
No koha-qa errors.

NOTE: It's impossible now to delete userid from interface.

Off-topic: tried an userid in Arabic, works very well.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 6 Marcel de Rooy 2013-03-26 14:54:13 UTC
Passed QA
Comment 7 Jared Camins-Esakov 2013-03-31 01:55:35 UTC
This patch has been pushed to master.
Comment 8 Chris Cormack 2013-04-24 21:46:56 UTC
Pushed to 3.10.x and 3.8.x will be in 3.10.6 and 3.8.13