http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10454
--- Comment #11 from M. Tompsett <[email protected]> --- (In reply to M. de Rooy from comment #10) Apologies for the reordering of your commentary. :) > With compliments for your hard work, but is it true that we spend so much > effort on this only because we want to see a cardnumber already before > hitting the Save button? No, the reason I did this is because of FIXME comments in places like C4::Input.pm and because the gap is larger in some places (like the above example) than others. Any chance of duplicates, no matter how small (in my opinion), is bad. > Why not simplify it by disabling the cardnumber and probably also the login > code fields for Insert Patron, generating them when saving the record and > just displaying them after that? I suppose we could disable or not display them if they are auto-generated, but if there is no auto-generation, we need to field visible and able to be entered. This would solve the skip generation problem, and make me much happier. But isn't whether to display or disable outside the scope of the initial problem? That is, limiting cardnumber generation to just before save is different than preventing duplicates, though it does overlap. > Note that e.g. we do not have a biblionumber too before saving a biblio > record, etc. (Some other fields like 001, 005 are also finalized only when > saving.) And I think that this idea of limiting in the case of auto-generation is a good one. It solves the fake skip problem (out of boredom hitting refresh). > From a glance through code, I feel that this routine fixup_cardnumber is > still quite confusing and complicated. Should it really be done this way? However, this patch (or something that at least serializes) is still necessary, because of the time gap between generation and insertion. Even if we shrink that gap, we don't eliminate the possibility of duplicates. This patch does. The reason this patch is complicated is to deal with the off-chance that someone attempts to generate a number, but the server crashes, before the calculated next value is inserted back into the sequence table. That would leave the previous value not calculated. This is why there is the loop, before returning the calculated value for the my_UID record. You will also note that this particular "number" (it's really a string for the 'katipo' value of checkdigit), can't be generalized as hoped for in bug 10478, because checkdigit is a cardnumber system preference. I really appreciate the feedback. I hope this reply makes sense. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
