6 May
2008
6 May
'08
9:03 a.m.
Hi Sorry for delay, >> -----Original Message----- >> From: koha-devel-bounces@lists.koha.org [mailto:koha-devel- >> bounces@lists.koha.org] On Behalf Of Galen Charlton >> Sent: Thursday, May 01, 2008 12:06 AM >> To: Koha-Devel >> Subject: [Koha-devel] RFC: alternate borrower IDs >> >> Hi, >> >> Various LibLime customers have requested the ability to have the >> borrower record store additional IDs beyond the barcode and OPAC user >> ID. To meet this requirement, we propose the following development, >> which barring a general escape of zombies from the sewers of Chicago, >> I could implement by the middle of next week. >> >> The concept of alternate (or additional) IDs would support the >> following use cases: >> >> [1] A (academic) library loads patron records for their students from >> CSV file extracted from a database run by the campus registrar. >> However, the registrar does not know or care about barcodes and >> userids assigned by the library; all they supply is a unique campus ID >> number that the library is expected to match against during patron >> imports. >> >> [2] A library has more than two identifiers for their patrons. Two >> types of identifiers can take passwords or PINs. >> >> [3] More broadly, and this is something that falls out of the specific >> implementation I'm about to propose, the library wants to add >> free-text attributes to the patron record that are not covered by the >> existing columns of the borrowers table. >> >> To implement this, two new database tables would be added: >> >> borrower_attribute_types (ID or attribute_types) >> * ID type code (e.g., INSTID) >> * ID type description (e.g., 'Campus student ID') >> * repeatable (whether or not a borrower record can have more than one >> ID of that type) >> * unique (whether or not the ID should be enforced as a unique >> identifier) >> * opac_display (whether or not the ID should display in the patron's >> account page) >> * password_allowed (whether or not a password can be associated with >> the ID and used for patron authentication) >> * staff_searchable (whether or not the ID can be searched in the >> staff interface) >> lacks 2 fields : - authorised_values related to this value - "tab" (0 1 2) to use to display the value (intranet memberdetail.pl). >> borrower_attributes >> * borrowernumber (foreign key) >> * ID type (foreign key) >> * attribute (text string containing the ID or attribute) >> * password (optional password associated with the ID) >> Do you mean there would be more than one password ? Is this really required ? >> The primary functional changes would be >> >> 1. new Administration page to define borrower ID types >> 2. new patron editing page to add, delete, or edit borrower ID types >> 3. additional pane or box in patron account tab in OPAC to display >> additional IDs >> 4. in staff client, ability to include one or more ID types in search >> box >> 5. ability to load alternate IDs via the patron import tool. This >> would be done by adding an optional column in the CSV file that would >> contain ID types and IDs. Any unique ID would act as a matchpoint. >> For example, the column might contain: >> >> "INSTID:12345, MAJOR:Physics, ADDLOGIN:abcdef/passwd" >> >> The new feature would be guarded by a syspref - if the preference is >> off, no sign of the additional IDs would display in the Administration >> menu, the patron editor, or the OPAC. >> I think this would boil down to do a kind of framework for patrons. This design looks good. This is what I thought would have to be done when I added multiple sort fields for a custom installation (I sent you the files I think). Maybe it doesnot go far enough : data types and input facilities (plugins or call to js functions) could be added. But our current memberentry page is not that handy for that kind of stuff. Friendly. -- Henri-Damien LAURENT