Most libraries are happy for the public to come to the OPAC and search the catalogue without being logged in. Others however (corporate libraries, private colleges) require the user to be logged in before the collection or any functionality is exposed. Koha currently supports the first approach. The second approach is achievable by adding jquery to the template (won't stop hacking) or by editing the perl code to set 'authnotrequired' value to '0' per page. Neither way is user-friendly or produces an elegant display. We propose adding a syspref 'OpacNotPublic' or similar which when set to 'OFF' will cause no change to current behaviour. When set to 'ON' a different template will be called by opacmain.pl that will display: - a login prompt similar to that for the staff client; - the value of opacsmallimage; - the value of opacheader; - the value of opaccredits. Not displayed on this page will be: - the search bar and the cart and list buttons; - the value of opacnav; - the value of opacmainuserblock. Upon logging in, the user is directed to 'opac-user.pl' as is the case now. Before we lodge on Bugzilla, are there any comments? Bob Birchall CALYX
Le 22/02/2010 06:43, Bob Birchall @ Calyx a écrit :
Before we lodge on Bugzilla, are there any comments?
yes: sound fine to me ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Mon, Feb 22, 2010 at 11:13 AM, Bob Birchall @ Calyx <bob@calyx.net.au> wrote: <snipped>
We propose adding a syspref 'OpacNotPublic' or similar which when set to 'OFF' will cause no change to current behaviour. When set to 'ON' a different template will be called by opacmain.pl that will display: - a login prompt similar to that for the staff client; - the value of opacsmallimage; - the value of opacheader; - the value of opaccredits. Not displayed on this page will be: - the search bar and the cart and list buttons; - the value of opacnav; - the value of opacmainuserblock.
Upon logging in, the user is directed to 'opac-user.pl' as is the case now.
Before we lodge on Bugzilla, are there any comments?
+1 -indra
+1 On Mon, Feb 22, 2010 at 4:39 AM, Indranil Das Gupta <indradg@gmail.com> wrote:
On Mon, Feb 22, 2010 at 11:13 AM, Bob Birchall @ Calyx <bob@calyx.net.au> wrote: <snipped>
We propose adding a syspref 'OpacNotPublic' or similar which when set to 'OFF' will cause no change to current behaviour. When set to 'ON' a different template will be called by opacmain.pl that will display: - a login prompt similar to that for the staff client; - the value of opacsmallimage; - the value of opacheader; - the value of opaccredits. Not displayed on this page will be: - the search bar and the cart and list buttons; - the value of opacnav; - the value of opacmainuserblock.
Upon logging in, the user is directed to 'opac-user.pl' as is the case now.
Before we lodge on Bugzilla, are there any comments?
+1
-indra _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
This is a good idea. However, I'm not sure that just calling a different template from opacmain.pl is enough. Unless I'm missing something, people will still be able to access other pages if they know the URL. I think that adding the OpacNotPublic is necessary. Why not using this value to set the 'authnotrequired' in the code, instead of having this value hardcoded. That way, every pages would be protected. My 2 cents. Eric Bégin inLibro Bob Birchall @ Calyx wrote:
Most libraries are happy for the public to come to the OPAC and search the catalogue without being logged in. Others however (corporate libraries, private colleges) require the user to be logged in before the collection or any functionality is exposed.
Koha currently supports the first approach. The second approach is achievable by adding jquery to the template (won't stop hacking) or by editing the perl code to set 'authnotrequired' value to '0' per page. Neither way is user-friendly or produces an elegant display.
We propose adding a syspref 'OpacNotPublic' or similar which when set to 'OFF' will cause no change to current behaviour. When set to 'ON' a different template will be called by opacmain.pl that will display: - a login prompt similar to that for the staff client; - the value of opacsmallimage; - the value of opacheader; - the value of opaccredits. Not displayed on this page will be: - the search bar and the cart and list buttons; - the value of opacnav; - the value of opacmainuserblock.
Upon logging in, the user is directed to 'opac-user.pl' as is the case now.
Before we lodge on Bugzilla, are there any comments?
Bob Birchall CALYX
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi, On Mon, Feb 22, 2010 at 9:11 AM, Eric Bégin <Eric.Begin@inlibro.com> wrote:
Why not using this value to set the 'authnotrequired' in the code, instead of having this value hardcoded. That way, every pages would be protected.
Agreed - this is more comprehensive. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
Sounds like a good starting place. More generally, I'd like to see visibility configured on a Patron Type/Item Type level. That is, items of type X can only be seen by patrons with item type X viewing permissions, with limits on whether patrons have to be from a specific library or library group. Perhaps this could be merged in with OPACSuppression field in the MARC record somehow.... this would allow us to This would certainly make configurations more difficult and time consuming, but having the option may be worth it to certain libraries. Documentation would need to be very clear. -Ian Walls On Mon, Feb 22, 2010 at 11:58 AM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Mon, Feb 22, 2010 at 9:11 AM, Eric Bégin <Eric.Begin@inlibro.com> wrote:
Why not using this value to set the 'authnotrequired' in the code, instead of having this value hardcoded. That way, every pages would be protected.
Agreed - this is more comprehensive.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
2010/2/22 Ian Walls <ian.walls@bywatersolutions.com>
Sounds like a good starting place.
More generally, I'd like to see visibility configured on a Patron Type/Item Type level. That is, items of type X can only be seen by patrons with item type X viewing permissions, with limits on whether patrons have to be from a specific library or library group.
I see this kind of granularity as a totally different problem than the initial one described, requiring the presence of much more data. I would avoid mixing these two up for now. ---joe
OK, thanks for the suggestion. We will add that to the spec. Regards, Bob
-----Original Message----- From: Galen Charlton [mailto:gmcharlt@gmail.com] Sent: Tuesday, 23 February 2010 3:58 AM To: Eric Bégin Cc: Bob Birchall @ Calyx; koha-devel Subject: Re: [Koha-devel] OPAC Secured
Hi,
On Mon, Feb 22, 2010 at 9:11 AM, Eric Bégin <Eric.Begin@inlibro.com> wrote:
Why not using this value to set the 'authnotrequired' in the code, instead of having this value hardcoded. That way, every pages would be protected.
Agreed - this is more comprehensive.
Regards,
Galen -- Galen Charlton gmcharlt@gmail.com No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.435 / Virus Database: 271.1.1/2703 - Release Date: 02/22/10 07:34:00
participants (8)
-
Bob Birchall ＠ Calyx -
Eric Bégin -
Galen Charlton -
Ian Walls -
Indranil Das Gupta -
Joe Atzberger -
Nicole Engard -
Paul Poulain