[Koha-bugs] [Bug 10454] Duplicate card numbers may be generated

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10454

--- Comment #11 from M. Tompsett <mtompset at hotmail.com> ---
(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.