+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
(<indr...@gmail.com <mailto:indr...@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/
_______________________________________________
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/
