http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8897
--- Comment #16 from Mirko Tietgen <[email protected]> --- (In reply to Robin Sheat from comment #15) > (In reply to Mirko Tietgen from comment #14) > > I was thinking to have the JS server-side, like we have jquery in Koha. > > But jquery runs client side. It doesn't make sense to run this client side, > as email generation happens without the interaction of a browser. True. I will look into that when i have more time to see if it is possible. I have only used the JS an afternoon so far. > > > Would that be a problem? I think it does not break the "OPAC needs to work > > without JS" rule as it is not a core functionality. We allow local JS in the > > OPAC too. > > I just can't see a place where encryption from the OPAC is something that's > generally useful. We don't send emails from there. Oh you are right of course, the only thing that needs to be done from the OPAC is to offer patrons a field to enter the public key. My bad. > > > About using a library key/passphrase, I'm not sure if you would have > > situations where you need to decrypt messages, add stuff and encrypt them > > again before sending the email. > > No, once they're added to the message queue, I don't think anything more > happens to them. They wouldn't be encrypted while working their way through > the running process, they'd presumably get encrypted just before putting > them in the queue (but I haven't looked at your code in forever.) I think there is an update sometimes when the same action is repeated, to only send one email about it covering all instances of that actions. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
