[Koha-devel] Request for discussion: bugs 3674, 6220, 6224 and 6218

Nicole Engard nengard at gmail.com
Tue Apr 26 18:33:57 CEST 2011


In the US, some libraries require that parents give their children
permission to access the system this means that if the child doesn't
have permission they shouldn't have a log in - so having all patrons
require a log in would be an issue in this situation.

That said I'm thinking we need a system that emails the patron a link
to activate their account and choose a password - that way we aren't
setting an arbitrary default and the librarians aren't assigning
passwords.  This is very common on sites these days.  Another option
is to allow the patron to register online for a card and when they do
that they choose their log in information - either of these options is
secure, but the latter may be a problem in some libraries that require
a form of identification to get a library card in the first place ....

Also a ranting answer from me, don't know if I made anything clearer
or just added more questions.

Nicole

On Tue, Apr 26, 2011 at 11:59 AM, Fernando Canizo <conan at lugmen.org.ar> wrote:
> I found bug 6220, the bug is the first paragraph only, the rest is me
> rambling on because I thought there were some default password for newly
> created koha users when no password was provided.
>
> 6224 explains the same bug better and without rambling.
>
> 3674 is an implementation of users with disabled login from biblibre.
>
> And 6218 has a tiny patch to auto generate logins upon user creation if none
> provided.
>
> These all leave me thinking:
>        1. what's the purpose of creating users? and
>        2. what would be desirable upon user creation?
>
> And those two questions is what I want to discuss here so answer may clear
> my view on this.
>
> There was some prior talking in the comments to bug 6220 with Katrin
> Fischer.
>
> The answer to my first question is pretty simple to me: we create users to
> use the system! But this leads to some defaults we were not enforcing:
>
> - they will require a login (implemented on my patch for 3674), we cannot
> allow users on database without a login
>
> - they will require a password. I think, but on biblibre it seems they need
> users with no password at all and also disabled users, which was implemented
> by making borrowers.password = '!'. It's not clear to me if they need both
> or just the = '!' one.
>
> This leads to the second question:
>
> - do we need empty passwords? or can we cope with disabled ones (='!')
>
> - if we allow disabled logins, then shouldn't we provide a way to
> disable/enable them (right now you can only get a disabled login upon user
> creation, and you cannot disable it again once you enabled it)
>
> - should it be desirable to have auto-generated passwords? If so, we need to
> decide if they would be viewable by superlibrarian upon creation (to tell it
> to the user), or if we silently will send it by mail directly to the user.
> If the second option is choosen, then we need to get sure
> KohaAdminEmailAddress is a valid email on installation and also require upon
> user creation to provide an email (and what if the user doesn't have one?)
>
> - KF also suggested these auto-generated passwords should be made 'one time
> only' and force user to provide a new one on first login, which means we
> would need to add a new column to database, something like
> borrowers.password_valid_until which should be a timestamp.
>
> I might be rambling again, so I'll summarize:
>
> - I think database should not have users which don't have a login defined.
> Then we should enforce it by default making
> systempreferences.BorrowerMandatoryField include OPAC login field, and also
> provide a mechanism to avoid empty logins just in case some superlibrarian
> modifies it.
>
> - I would like to hear from you to know how to close all these
> bugs/enhancements propositions.
>
> --
> Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
> GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>


More information about the Koha-devel mailing list