When you send an email from the cart, it says, "[Blank] sent you a cart..." I'm guessing that this is because the patron is not logged in, but perhaps this line shouldn't be in the email if the patron isn't logged in to avoid confusion.
The template was modified as part of Bug 3651 (Require patron login to send shelves and baskets) to operate under the assumption that one *must* be logged in to send a Cart. This requirement was undone by Bug 4289, which tied the login requirement to whether the OpacPublic syspref is on or off.
I have submitted a follow-up patch for Bug 3651 which will once again require that the user be logged in to send a cart or a list. That should invalidate this bug.
There's still the question of whether this is the way things should work (Bug 4274 - Cart now requires login before emailing contents), but my patch for Bug 3651 will at least return things to the state they were in most recently.
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.
(In reply to comment #3)
> I personally don't think we should require login to mail a cart.
Sure, that's the discussion under Bug 4274. But I think the best fix for this bug, as long as Bug 4274 is undecided, is to revert the cart behavior to what it was most recently.
I agree with Nicole and others who noted on Bug 4274 that we should not force users to login to use the cart. The Brooklyn Public Library catalog for example, doesn't require a login to e-mail a cart.
I can think of 2 examples where not requiring login for carts is useful so far. 1) A reference-only, non-circulating library uses Koha but doesn't need to implement public user accounts. 2) A researcher uses a catalog of a unique special library that does it's own original cataloging. The researcher is from another location and is not allowed to join the library and circulate books there. That person can still benefit from having a cart feature to e-mail citations to himself so that he can find those books at a local library.
If you require login, you are basically taking a userful feature away from certain users and libraries.
In summary, it seems it makes sense to have a condition in the code to not include the "[Blank] sent you a cart..." line in the cart when a user is not logged in.
The tickets related to cart security issues don't seem to be loading at the moment, but perhaps there are other ways to deal with them?
(In reply to comment #5)
> I agree with Nicole and others who noted on Bug 4274 that we should not force
> users to login to use the cart.
I think a comment on Bug 4274 is in order.
> The tickets related to cart security issues don't seem to be loading at the
> moment, but perhaps there are other ways to deal with them?
The bug report which led to the required login is Bug 3651.
I agree with Owen,
Putting the behaviour back as it was (ie removing the regression) is the first step.
Then on 4274 people can come up with a way for the cart to be used without logging in and without being used as spam tool and without captcha.
That may take a while so lets fix the regression first while people discuss that.
Bug 3651 is signed off, so it can be QAed and pushed, while people figure out how to implement bug 4274 is an robust and secure manner.
PS Regressions suck
Chris and Owen, Does the current fix you are suggesting (requiring login to e-mail cart) still allow a person who is not logged-in to search the catalog and print/download the cart? If yes, does the clicking on the "Send" link prompt the message, "You must be logged in to e-mail this cart"?
(In reply to comment #8)
> Chris and Owen, Does the current fix you are suggesting (requiring login to
> e-mail cart) still allow a person who is not logged-in to search the catalog
> and print/download the cart? If yes, does the clicking on the "Send" link
> prompt the message, "You must be logged in to e-mail this cart"?
The fix reverts the regression and puts it back how it was before in was accidentally changed.
The other bug can then be used to change, on purpose.
If I was you I would focus my energy on bug 4274, not this one. Bug 3651 puts the behaviour of the cart send, list send and opac-userudpate back as they were. It has been signed off, and should be pushed as soon as possible because currently, people could send an userupdate request without being logged in also.
And yes it is only sending the cart, printing and downloading don't require logging in.
But again, security is more important here, and bug 3651 should have its patch pushed and then people can work on how to do anonymous cart sending in a safe manner.