Suggestions requested for a feature / enhancement based around opac-retrieve-file.pl
Hi all, the current Koha::Upload.pm and opac-retrieve-file.pl allows for a uploaded file (e.g. PDF) to be displayed on the OPAC as long as the flag is set to public. I know how many librarians feel about reader history privacy and they are protective about it for good reason. In this context, I'm faced with the following two use-cases: In India, e-books with archival rights are gaining ground over hardcopy. As it happens the buyer (institutional library) has to give an undertaking that it will implement reasonable safeguards to ensure that while all their bonafide users should have access to the books, these shall not be presented to the users in such as way as to permit un-monitored access / downloads by un-authenticated users etc along with maintenance of any access log for any necessary compliance. Or for example PhD theses where many institutions across India have an embargo on the full-text online access for non-members for a period upto 2 years from the date of publication, but no such restriction exist for bonafide authorised users. I am working on an early stage prototype to support this sort of functionality. My question here to you all is that how far are we open as devs and librarians to accept such an extension into Koha? Of course, there would be a syspref that will have to be set for the functionality to kick in. Suggestions? Comments? regards indranil -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg
It's a simple addition I've been thinking of too. Adding the 'logged in user' option to file uploads. It should be very simple to implement. +1 from me. El dom., 25 jun. 2017 a las 19:15, Indranil Das Gupta (<indradg@gmail.com>) escribió:
Hi all,
the current Koha::Upload.pm and opac-retrieve-file.pl allows for a uploaded file (e.g. PDF) to be displayed on the OPAC as long as the flag is set to public.
I know how many librarians feel about reader history privacy and they are protective about it for good reason. In this context, I'm faced with the following two use-cases:
In India, e-books with archival rights are gaining ground over hardcopy. As it happens the buyer (institutional library) has to give an undertaking that it will implement reasonable safeguards to ensure that while all their bonafide users should have access to the books, these shall not be presented to the users in such as way as to permit un-monitored access / downloads by un-authenticated users etc along with maintenance of any access log for any necessary compliance.
Or for example PhD theses where many institutions across India have an embargo on the full-text online access for non-members for a period upto 2 years from the date of publication, but no such restriction exist for bonafide authorised users.
I am working on an early stage prototype to support this sort of functionality. My question here to you all is that how far are we open as devs and librarians to accept such an extension into Koha? Of course, there would be a syspref that will have to be set for the functionality to kick in.
Suggestions? Comments?
regards indranil
-- Indranil Das Gupta L2C2 Technologies
Phone : +91-98300-20971 <+91%2098300%2020971> WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg _______________________________________________ Koha-devel mailing list Koha-devel@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/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
+1 from me Questions: - Where would the information go about downloadability (and availability, see below)? (Biblio record, item record...) - Will there be a need for granularity, e.g. allow download only for users of a certain user type (Staff, Teacher...)? A related functionality could be to mark items (of any type) to be hidden in search results for non logged in users. Similar to AgeRestrictionMarker and/or OpacSuppression ( Hide items marked as suppressed from OPAC search results. ) Then it would be a good idea to manage an "embargo date". Such downloads (and/or items) would automatically become available / visible after a certain date. Just my 2 cents :-) Marc Am 26.06.2017 um 07:50 schrieb Tomas Cohen Arazi:
It's a simple addition I've been thinking of too. Adding the 'logged in user' option to file uploads. It should be very simple to implement. +1 from me.
El dom., 25 jun. 2017 a las 19:15, Indranil Das Gupta (<indradg@gmail.com <mailto:indradg@gmail.com>>) escribió:
Hi all,
the current Koha::Upload.pm and opac-retrieve-file.pl <http://opac-retrieve-file.pl> allows for a uploaded file (e.g. PDF) to be displayed on the OPAC as long as the flag is set to public.
I know how many librarians feel about reader history privacy and they are protective about it for good reason. In this context, I'm faced with the following two use-cases:
In India, e-books with archival rights are gaining ground over hardcopy. As it happens the buyer (institutional library) has to give an undertaking that it will implement reasonable safeguards to ensure that while all their bonafide users should have access to the books, these shall not be presented to the users in such as way as to permit un-monitored access / downloads by un-authenticated users etc along with maintenance of any access log for any necessary compliance.
Or for example PhD theses where many institutions across India have an embargo on the full-text online access for non-members for a period upto 2 years from the date of publication, but no such restriction exist for bonafide authorised users.
I am working on an early stage prototype to support this sort of functionality. My question here to you all is that how far are we open as devs and librarians to accept such an extension into Koha? Of course, there would be a syspref that will have to be set for the functionality to kick in.
Suggestions? Comments?
regards indranil
-- Indranil Das Gupta L2C2 Technologies
Phone : +91-98300-20971 <tel:+91%2098300%2020971> WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net <http://irc.freenode.net> Twitter : indradg _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@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/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
_______________________________________________ Koha-devel mailing list Koha-devel@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/
Sounds as an acceptable improvement. Could be handled with a syspref of course. Would be the easiest solution to implement. But we could also extend the meaning of Public here. And make a division between Private, Restricted and Public. Restricted could be handled by allowing patron types, as Marc suggested ? Or patron lists ? Or ... More flexible than just a true/false flag. Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Indranil Das Gupta Verzonden: maandag 26 juni 2017 00:15 Aan: koha-devel@lists.koha-community.org Onderwerp: [Koha-devel] Suggestions requested for a feature / enhancement based around opac-retrieve-file.pl Hi all, the current Koha::Upload.pm and opac-retrieve-file.pl allows for a uploaded file (e.g. PDF) to be displayed on the OPAC as long as the flag is set to public. I know how many librarians feel about reader history privacy and they are protective about it for good reason. In this context, I'm faced with the following two use-cases: In India, e-books with archival rights are gaining ground over hardcopy. As it happens the buyer (institutional library) has to give an undertaking that it will implement reasonable safeguards to ensure that while all their bonafide users should have access to the books, these shall not be presented to the users in such as way as to permit un-monitored access / downloads by un-authenticated users etc along with maintenance of any access log for any necessary compliance. Or for example PhD theses where many institutions across India have an embargo on the full-text online access for non-members for a period upto 2 years from the date of publication, but no such restriction exist for bonafide authorised users. I am working on an early stage prototype to support this sort of functionality. My question here to you all is that how far are we open as devs and librarians to accept such an extension into Koha? Of course, there would be a syspref that will have to be set for the functionality to kick in. Suggestions? Comments? regards indranil -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg _______________________________________________ Koha-devel mailing list Koha-devel@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/
Salvete! I would be surprised if this is very different from some of the other authentication work that has already been done. ByWater did work with OverDrive that might be useful to think about. There are numerous ways to handle this. You could create a verified user category. They would then be alerted to the fact that you have to keep a maintenance log on access to certain files. This could be a simple email linked to a form, which the Library could then track and compile to verify that they did indeed opt in on a certain date. As long as your form fields were clever, you could automate the log for your Library staff. The kicker for me is flexibility. Are you going to want a user, like a Professor or Department Chair, that will need access to everything the Library offers? Each thing with a paywall or barrier might warrant an articulation. For example, I might need access to PhD theses and Overdrive but not databases. Talk to your Library staff to see just who needs access to what so that there are a lot of plugs on the metaphorical authentication power strip. Hope this helped, Brooke
participants (5)
-
BWS Johnson -
Indranil Das Gupta -
Marc Véron -
Marcel de Rooy -
Tomas Cohen Arazi