Bug 4274

Summary: Optionally allow sending cart without requiring login
Product: Koha Reporter: Jane Wagner <jwagner>
Component: OPACAssignee: Bugs List <koha-bugs>
Status: CLOSED WONTFIX QA Contact: Bugs List <koha-bugs>
Severity: enhancement    
Priority: P5 - low CC: andrewfh, chris, dcook, jimmy012012, jonathan.druart, katrin.fischer, kelly, m.de.rooy, marjorie.barry-vila, nblake, Niamh.WalkerHeadon, schulera, siobhancottam, tomascohen, wizzyrea
Version: Main   
Hardware: PC   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3280
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Chris Cormack 2010-05-21 01:25:15 UTC


---- Reported by jwagner@ptfs.com 2010-02-25 18:58:43 ----

I'm not sure if this is a bug or a feature.  It's one of the options discussed in http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3280 for improving cart email security.  In 3.0.x, the OPAC cart could be emailed by any user.  At current head, the cart forces the user to log into the OPAC before it will email the contents of the cart.  Is this intentional?  Is it desirable?



---- Additional Comments From jwagner@ptfs.com 2010-02-25 19:13:31 ----

See http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3651 which seems to have set this.  I think it should be configurable, so that libraries could use a syspref to turn it on/off.  Is there any way to do it so that users don't have to log in to send a cart but security is preserved?




---- Additional Comments From jwagner@ptfs.com 2010-02-25 19:20:16 ----

Also see http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3280 about cart security.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:25 UTC  ---

This bug was previously known as _bug_ 4274 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4274

Unknown operating system Windows 2000. Setting to default OS "All".
Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was jwagner@ptfs.com.
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 schulera 2010-11-17 19:51:52 UTC
I would also like to see this changed, so that users do not have to be logged in to use the cart/e-mail feature.
Comment 2 Tomás Cohen Arazi 2010-12-02 17:53:38 UTC
We could implement a CAPTCHA for this
Comment 3 Nicole C. Engard 2011-12-30 13:42:51 UTC
I personally don't think we should require login to mail a cart. What if I'm in
the library at a public terminal and want to email a list of titles to myself,
making me log in means I have to remember to log out of the public computer.

Also Captcha is not accessibility friendly.
Comment 4 jimmy012012 2012-01-05 16:14:41 UTC
My comments on Bug 7383 might be more appropriate here:

Basically, I agreeing that the e-mail cart feature is quite useful as a standard saving feature, and to require login is too restrictive for:

1) reference-only libraries that don't circulate and don't require user accounts.

2) researchers using a special library's catalog at another location and does not have a user account.

It would be great if we can figure out a solution so that it's easier for users to e-mail citations to themselves for later research.
Comment 5 Nora Blake 2012-01-31 16:58:53 UTC
Hi,

I'd like to chime in that requiring a username and password in order to email cart contents is not an improvement in our eyes.  We have a lot of school libraries as members of our shared system.  They don't necessarily want their students to have usernames and passwords to access the system, but they would like to be able to have the kids email contents of carts either to the staff librarian so they can place holds on behalf of the students or so that students can do research and email the results of that search to themselves to use later.

Having this access now blocked by a username and password is not good.  I'd like it to be restored to what it was before or at the very least have username and password access to cart contents be a on/off switch in the system administration.

Thanks,

Nora Blake
MassCat
Comment 6 Chris Cormack 2012-01-31 17:08:43 UTC
(In reply to comment #5)
> Hi,
> 
> I'd like to chime in that requiring a username and password in order to email
> cart contents is not an improvement in our eyes.  We have a lot of school
> libraries as members of our shared system.  They don't necessarily want their
> students to have usernames and passwords to access the system, but they would
> like to be able to have the kids email contents of carts either to the staff
> librarian so they can place holds on behalf of the students or so that students
> can do research and email the results of that search to themselves to use
> later.
> 
> Having this access now blocked by a username and password is not good.  I'd
> like it to be restored to what it was before or at the very least have username
> and password access to cart contents be a on/off switch in the system
> administration.
> 
What it was before was needing login, then that got broken by accident with the opacpublic changes, then it was restored. 

The main reason being, it's a spam tool otherwise, so before we can let it be used without a login, someone needs to propose a solution that will stop spammers using it, that isn't using captcha or another discriminatory technique. Then we are good to go with a syspref.
Comment 7 David Cook 2015-03-25 22:26:00 UTC
(In reply to Chris Cormack from comment #6)
> (In reply to comment #5)
> The main reason being, it's a spam tool otherwise, so before we can let it
> be used without a login, someone needs to propose a solution that will stop
> spammers using it, that isn't using captcha or another discriminatory
> technique. Then we are good to go with a syspref.

Perhaps a negative captcha like we're now using for the Anonymous Suggestions as per bug 3144?

I included some links on Comment 24 with some information. 

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3144#c24
Comment 8 Katrin Fischer 2015-03-25 22:36:00 UTC
A human being might still misuse the feature - I think it should be a choice  for the library, so they can turn off 'non logged in cart sending'.
Comment 9 David Cook 2015-03-25 22:37:19 UTC
(In reply to Katrin Fischer from comment #8)
> A human being might still misuse the feature - I think it should be a choice
> for the library, so they can turn off 'non logged in cart sending'.

Agreed. We actually have this implemented locally as an "anonymous cart" system preference. I think most of our libraries have it turned off (ie require login), but a few want anyone to be able to use the cart.
Comment 10 Jonathan Druart 2019-04-29 00:00:39 UTC
(In reply to David Cook from comment #9)
> (In reply to Katrin Fischer from comment #8)
> > A human being might still misuse the feature - I think it should be a choice
> > for the library, so they can turn off 'non logged in cart sending'.
> 
> Agreed. We actually have this implemented locally as an "anonymous cart"
> system preference. I think most of our libraries have it turned off (ie
> require login), but a few want anyone to be able to use the cart.

Still have the code somewhere?
Comment 11 David Cook 2019-04-29 00:09:23 UTC
(In reply to Jonathan Druart from comment #10)
> (In reply to David Cook from comment #9)
> > (In reply to Katrin Fischer from comment #8)
> > > A human being might still misuse the feature - I think it should be a choice
> > > for the library, so they can turn off 'non logged in cart sending'.
> > 
> > Agreed. We actually have this implemented locally as an "anonymous cart"
> > system preference. I think most of our libraries have it turned off (ie
> > require login), but a few want anyone to be able to use the cart.
> 
> Still have the code somewhere?

Yes, although we've customized the cart quite a bit, so it would take time, which I don't have, to unravel it enough to share. 

Basically, I think you have a system preference, and enable $authnotrequired where necessary and add Koha.Preference( '<anonymous cart>' ) where necessary in the templates.

I could look at this another time, but need to focus on other things atm.
Comment 12 Andrew Fuerste-Henry 2019-08-20 12:20:32 UTC
Chiming in that I'm currently training a library that doesn't have patron records and therefore doesn't allow opac login but would like to be able to email the cart. So it'd be great to see this move forward. Thanks!
Comment 13 David Cook 2019-08-22 02:49:26 UTC
(In reply to Andrew Fuerste-Henry from comment #12)
> Chiming in that I'm currently training a library that doesn't have patron
> records and therefore doesn't allow opac login but would like to be able to
> email the cart. So it'd be great to see this move forward. Thanks!

Unfortunately, I'm swamped with other work, so it's not on my list of priorities.
Comment 14 Liz Rea 2019-09-06 01:05:27 UTC
David, 

any chance you could push the branch you've got this code in somewhere public, so we could do the work of pulling this feature out for you?

Seems a pity to have to re-engineer it.

Cheers,
Liz
Comment 15 Katrin Fischer 2020-03-15 16:33:13 UTC
*** Bug 24579 has been marked as a duplicate of this bug. ***
Comment 16 Katrin Fischer 2023-01-07 21:45:56 UTC
I am not sure if this is a feature that we should implement given the possible security/spam implications. A bot or human misusing the feature could get the library's email address blacklisted for example.

Would someone else support a CLOSED WONTFIX?
Comment 17 Marcel de Rooy 2023-01-09 08:03:38 UTC
(In reply to Katrin Fischer from comment #16)
> I am not sure if this is a feature that we should implement given the
> possible security/spam implications. A bot or human misusing the feature
> could get the library's email address blacklisted for example.
> 
> Would someone else support a CLOSED WONTFIX?

Yes, we should close it.