[Koha-devel] RFC: alternate borrower IDs

[Henri-Damien LAURENT]

Hi
Sorry for delay,
>> -----Original Message-----
>> From: koha-devel-bounces at lists.koha.org [mailto:koha-devel-
>> bounces at 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