Interested to see what you've started Jonathan,
In rebus:list we used Minion, the job queue spin-off project from the same
guys that wrote Mojolicious. Granted, it works best with a PostgreSQL
backend, but I believe there are MySQL backends too.. I'd probably start
there... the more I worked with
I recently wrote to Nick about this as well:
http://lists.koha-community.org/pipermail/koha-devel/2018-June/044605.html. I
wrote my own job server for Bug 10662 but figured the Koha community would
never accept it, so I scrapped it and made a purpose-built scheduler just for
OAI-PMH harvesting,
Considering that the borrower’s password is typically in the ACCTDETAILS email,
I think using the message_queue for ACCTDETAILS would be a bad idea and would
probably violate the GDPR in Europe.
Just imagine looking through your database and seeing all those plain text
passwords, especially
Considering that email is plaintext (AKA "postcard") mail, I'm surprised we
would send a user's password in an email in any case.
On Mon, Jun 18, 2018 at 4:14 AM, David Cook
wrote:
> Considering that the borrower’s password is typically in the ACCTDETAILS
> email, I think using the message_queue
My work was focused on the issue we face for background jobs.
I have just pushed my local branch to
https://gitlab.com/joubu/Koha/commits/bug_15032_other_tries (last 7 commits)
There is nothing to process the queued jobs actually, so I guess it is not
what you expected.
IIRC my conclusion was that
Nice idea I would say.
I think may PHP softwares with plugins do this and you usually have only
1 job in crontab ^ ^
Le 07/06/2018 à 19:47, Nick Clemens a écrit :
Just an idea I had an bounced off Kyle, he suggested sending it out for
feedback, let us knwo what you think:
https://bugs.koha-co
It has been reported (by David) on our bug tracker already (20796, security
area, which does no longer make sense at it is public now...)
For information this notice contains the password in clear for... 10 years
now (bug 2149) and the behavior is turned off by default
(AutoEmailOpacUser).
On Mo
Hi Andreas,
I might be misunderstanding your question, but the OPAC visibility
setting should take effect on all pages and views in the OPAC now. It
didn't use to, which was considered a long standing bug and finally
fixed. Now it's possible to hide fields from OPAC that can still appear
in s
I've filed
Bug 20961 : cn_sort for DDC callnumbers should between 1 and 99 should be
formatted as 001.* - 099.*
URL :
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20961
Priority: P5 - low
Assigned To : koha-b...@lists.koha-community.org
Urgency : enhancement
Status
Cheers, Jonathan. I had totally forgotten about that. Yikes.
Good call, Chris. While I think many mail servers these days use TLS to secure
the email between the mail servers, an unscrupulous administrator could still
certainly take advantage of people on either end. The best idea probably is
I feel like instead of sending people a password, we should send them to
the "forgot password reset page" with a couple of slight changes for new
account holders, so they can set their own passwords.
Seems better than sending the password in the clear in an email.
Cheers,
Liz
On 19/06/18 12:21,
11 matches
Mail list logo
