When adding (or editing) a Patron Attribute, the option to "Allow password" can be selected. The purpose here is to allow this attribute/password to be a secondary login for the patron account. [ Allow password: Check to make it possible to associate a password with this attribute ] However, checking the box and then adding a patron with an attribute/password combination does not allow the patron to log on using that attribute password combination. 1. Set up New Patron Attribute, clicking Allow password option. 2. Create a new patron. Enter patron data including the attribute and password value 3. Save patron 4. Using that attribute/password values, attempt to log on to the OPAC.
Hi Joy, I am not sure if that was the purpose of the field. The way someone explained it to me in the past was, that it allows you to store a password for another application.
(In reply to Katrin Fischer from comment #1) > Hi Joy, I am not sure if that was the purpose of the field. The way someone > explained it to me in the past was, that it allows you to store a password > for another application. Actually, Joy's right - the original intent was to support secondary logins.
(In reply to Galen Charlton from comment #2) > (In reply to Katrin Fischer from comment #1) > > Hi Joy, I am not sure if that was the purpose of the field. The way someone > > explained it to me in the past was, that it allows you to store a password > > for another application. > > Actually, Joy's right - the original intent was to support secondary logins. http://lists.koha-community.org/pipermail/koha-patches/2008-May/000988.html - password_allowed (if set, staff patron editor will allow a password to be associated with a value; this is mostly a hook for functionality to be implemented in the future. Does it mean we should keep it or the feature won't never be implemented and we can remove the 2 columns in DB?
(In reply to Jonathan Druart from comment #3) > Does it mean we should keep it or the feature won't never be implemented and > we can remove the 2 columns in DB? About one year since this question was asked. Anyone got an opinion?
If the feature hasn't been implemented yet... I say remove it.
Created attachment 50122 [details] [review] Bug 12267: Remove borrower_attributes.password When creating a patron attribute type, there is a "Allow password" checkbox. If checked, the librarian will be able to enter a password for this patron attribute when editing a patron. The goal was to allow a patron to log in with a secondary password. However, this feature has never been implemented. """ commit 6fc62bcd321eddb0fd3ae46903e9ab6c8b1db2cd CommitDate: Mon May 12 09:03:00 2008 -0500 extended patron attributes tables & syspref (DB rev 081) - password_allowed (if set, staff patron editor will allow a password to be associated with a value; this is mostly a hook for functionality to be implemented in the future. """ To decrease maintainability, this patch suggest to remove the 2 DB fields borrower_attributes.password and borrower_attribute_types.password_allowed If they have not used by the library. Test plan: - Edit a patron attribute type and select "allow password" - Edit a patron and defined a password for this attribute - Execute the DB entry - Note that you get a warning - Empty the password field - Execute the DB entry - You do not get the warning and the 2 DB fields have been removed
Comment on attachment 50122 [details] [review] Bug 12267: Remove borrower_attributes.password Review of attachment 50122 [details] [review]: ----------------------------------------------------------------- ::: C4/Members/AttributeTypes.pm @@ +217,3 @@ > ?, ?, ?, ?, ?, ?)"); > } > + $sth->execute( $self->{description}, $self->{repeatable}, $self->{unique_id}, $self->{opac_display}, $self->{staff_searchable}, $self->{authorised_value_category}, $self->{display_checkout}, $self->{category_code} || undef, $self->{class}, $self->{code} ); Keeping it vertical would have been easier to read.
Created attachment 50140 [details] [review] Bug 12267: Remove borrower_attributes.password When creating a patron attribute type, there is a "Allow password" checkbox. If checked, the librarian will be able to enter a password for this patron attribute when editing a patron. The goal was to allow a patron to log in with a secondary password. However, this feature has never been implemented. """ commit 6fc62bcd321eddb0fd3ae46903e9ab6c8b1db2cd CommitDate: Mon May 12 09:03:00 2008 -0500 extended patron attributes tables & syspref (DB rev 081) - password_allowed (if set, staff patron editor will allow a password to be associated with a value; this is mostly a hook for functionality to be implemented in the future. """ To decrease maintainability, this patch suggest to remove the 2 DB fields borrower_attributes.password and borrower_attribute_types.password_allowed If they have not used by the library. Test plan: - Edit a patron attribute type and select "allow password" - Edit a patron and defined a password for this attribute - Execute the DB entry - Note that you get a warning - Empty the password field - Execute the DB entry - You do not get the warning and the 2 DB fields have been removed
(In reply to M. Tompsett from comment #7) > Comment on attachment 50122 [details] [review] [review] > Bug 12267: Remove borrower_attributes.password > > Review of attachment 50122 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: C4/Members/AttributeTypes.pm > @@ +217,3 @@ > > ?, ?, ?, ?, ?, ?)"); > > } > > + $sth->execute( $self->{description}, $self->{repeatable}, $self->{unique_id}, $self->{opac_display}, $self->{staff_searchable}, $self->{authorised_value_category}, $self->{display_checkout}, $self->{category_code} || undef, $self->{class}, $self->{code} ); > > Keeping it vertical would have been easier to read. Patch amended.
I am a bit worried about removing those - could we bring this up on the mailing list? Would it be possible that people used it as a hook to store login information other applications? When testing I noticed it stores the password in the database as cleartext, while hiding it **** in the GUI.
The column is deleted if not null, so we won't loose data. The idea to store password as text in DB is a really bad one, and nobody should use this field.
(In reply to Katrin Fischer from comment #10) > I am a bit worried about removing those - could we bring this up on the > mailing list? https://lists.katipo.co.nz/pipermail/koha/2016-April/045235.html
That's a good point actually.
On April 12 Marc Veron signed off, but forgot to add a signoff line. Will add that now.
Created attachment 50573 [details] [review] Bug 12267: Remove borrower_attributes.password When creating a patron attribute type, there is a "Allow password" checkbox. If checked, the librarian will be able to enter a password for this patron attribute when editing a patron. The goal was to allow a patron to log in with a secondary password. However, this feature has never been implemented. """ commit 6fc62bcd321eddb0fd3ae46903e9ab6c8b1db2cd CommitDate: Mon May 12 09:03:00 2008 -0500 extended patron attributes tables & syspref (DB rev 081) - password_allowed (if set, staff patron editor will allow a password to be associated with a value; this is mostly a hook for functionality to be implemented in the future. """ To decrease maintainability, this patch suggest to remove the 2 DB fields borrower_attributes.password and borrower_attribute_types.password_allowed If they have not used by the library. Test plan: - Edit a patron attribute type and select "allow password" - Edit a patron and defined a password for this attribute - Execute the DB entry - Note that you get a warning - Empty the password field - Execute the DB entry - You do not get the warning and the 2 DB fields have been removed Signed-off-by: Marc Veron <veron@veron.ch> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 50574 [details] [review] Bug 12267: [QA Follow-up] Adjust installer files; tiny text edit Some installer files still refer to password_allowed. The print statement of the db revision has been slightly adjusted. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
@RM: Please do not forget to update the DBIx schema !
Pushed to Master - Should be in the May 2016 Release. Thanks! (running schema updates right now too)
@Rm Please update schema files.
t/db_dependent/Members/Attributes.t adjusted on bug 16377
And still another one: t/db_dependent/ILSDI_Services.t on bug 16320