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) borrower_attributes * borrowernumber (foreign key) * ID type (foreign key) * attribute (text string containing the ID or attribute) * password (optional password associated with the ID) 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 would appreciate comments on this proposed functionality, the proposed implementation, and whether or not this would be of use to others. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
I run koha in an academic library setting and I can declare the functionality will be hugely useful to my library and a couple others I know especially the Academic bit and the free text bits. And just for record the bit about getting data from other databases would also apply in a corporate setting with users being drawn from a HR or payroll application (again unique IDs that are not 'library based') ======================= Bernard Shiundu Systems Librarian, Strathmore University Nairobi, Kenya
-----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)
borrower_attributes * borrowernumber (foreign key) * ID type (foreign key) * attribute (text string containing the ID or attribute) * password (optional password associated with the ID)
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 would appreciate comments on this proposed functionality, the proposed implementation, and whether or not this would be of use to others.
Regards,
Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
_______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
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
Hi, On Tue, May 6, 2008 at 3:03 AM, Henri-Damien LAURENT <laurenthdl@alinto.com> wrote: > >> From: koha-devel-bounces@lists.koha.org [mailto:koha-devel- > >> bounces@lists.koha.org] On Behalf Of Galen Charlton [snip] > >> > lacks 2 fields : > - authorised_values related to this value Good idea. > - "tab" (0 1 2) to use to display the value (intranet memberdetail.pl). For now, I'm inclined to use a set area for displaying and editing the alternate IDs and borrower attributes, rather than make the tab customizable. > >> * password (optional password associated with the ID) > >> > Do you mean there would be more than one password ? Is this really > required ? Yes, it is a requirement of the customer (although I grant that multiple passwords are not likely needed by most Koha users). > 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. A redesign of the patron entry page may be good, but I'm not planning on any major refactoring work for the sake of this specific feature. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
participants (3)
-
Bernard Shiundu -
Galen Charlton -
Henri-Damien LAURENT