http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7067
Liz Rea <wizzy...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion CC| |wizzy...@gmail.com --- Comment #2 from Liz Rea <wizzy...@gmail.com> 2012-02-08 17:22:41 UTC --- (In reply to comment #1) > Moving this discussion from Bug 1153: > > (In reply to comment #3) > > That sounds like an excellent idea. We could even have printable temporary > > library cards! One issue: my library system requires a piece of mail to > > verify > > a home address. What do other libraries require? Should it include the > > ability > > to submit scanned documents, or should just let you fill out your data, > > bring > > your documents in and let a librarian verify and complete the process. > > > > (In reply to comment #2) > > > I think we have a great opportunity to integrate and update to this > > > system with > > > a system for online patron registration: Both could potentially use the > > > same > > > table to store information which would require the librarian to validate > > > and > > > approve. > > I think the idea merits a wider discussion but I would propose: > > - Allow, or not, the user to submit a new registration online. > > - Allow, or not, the online registration to become fully active > automatically. If not: > > - Allow, or not, that online registration to give the user "probationary" > privileges in the OPAC and for the purposes of SIP authentication. In > other words, the patron can place holds, but the library might require > documentation upon pickup. Or the patron might be able to access > electronic resources which are authenticated against Koha's patron table. Maybe a new hard-coded patron category type of "provisional" that you can then assign any patron category code? Category codes in "provisional" have special rules that can be granularly defined: * can place holds (x number of holds, or not at all) * can authenticate via SIP (for x period, or not at all) * can circulate (x times, or not at all) * can only circulate items (not) of type x (say, you can't check out new dvd's as a provisional patron - how rude, but I can so see libraries doing it). * Alert staff every visit to any patron info page *this is a provisional patron - pursue creating permanent patron!* Additional functionality: * Crons to expire and/or remove provisional patrons, or at least report them out so they can be manually pursued. > > In the latter two cases Koha would need to email a response to the user so > that > they could activate their account (and so that we could validate the email). A > cron job could be set up to delete accounts which hadn't been activated after > a > certain number of days. I like the idea of at least requiring a valid email address and forcing activation of the account by clicking a link from the email. It would have to be optional, of course. Practically speaking, I think this fits under Patron Categories administration. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/