January 2016 - Koha-bugs - lists.koha-community.org

[Bug 15680] New: Fresh install of Koha cannot find any dependencies
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '16

12 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15680 Bug ID: 15680 Summary: Fresh install of Koha cannot find any dependencies Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It seems that on master, after clearing my database, one can no longer perform a fresh install. Koha seems to fail to find any of the installed Perl modules it depends on. This happens on master. The latest 3.22 finds the dependencies without a problem. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 15710] New: Kohacon 2015 is missing in the list of Kohacons
by bugzilla-daemon＠bugs.koha-community.org 01 Feb '16

01 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15710 Bug ID: 15710 Summary: Kohacon 2015 is missing in the list of Kohacons Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: mirko(a)abunchofthings.net There is no entry for Kohacon 2015 in Nigeria on the Kohacon subpage https://koha-community.org/kohacon/ -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 15709] New: Main navigation looks funny
by bugzilla-daemon＠bugs.koha-community.org 01 Feb '16

01 Feb '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15709 Bug ID: 15709 Summary: Main navigation looks funny Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: mirko(a)abunchofthings.net It seems like the entry for Kohacon 2012 is missing under "Kohacon", but we have the Kohacon 2012 schedule and sponsors as main entries. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 12051] add renew tab to top on staff client
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '16

31 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12051 Aleisha Amohia <aleishaamohia(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |15706 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15706 [Bug 15706] Templates require circulate permissions to show circ related tabs when they should only require circulate_remaining_permissions -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15450] koha-community.org/kohacon/ needs update
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '16

31 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15450 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |katrin.fischer(a)bsz-bw.de Status|NEW |RESOLVED --- Comment #2 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- This is fixed - 2 other bugs exist for other minor changes. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8897] Optional GnuPG encryption of outgoing emails
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '16

31 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8897 --- Comment #43 from Mirko Tietgen <mirko(a)abunchofthings.net> --- I will change the patch to store a keyid per user email address in Koha and make GnuPG.pm use that for all relevant operations. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15532] Add ability to allow only items whose home/holding branch matches the hold's pickup branch to fill a given hold
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '16

31 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15532 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |15708 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15708 [Bug 15708] Add ability to allow only items whose home/holding branch matches one of a group of libraries to fill a given hold -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14689] Marc field 648 does not appear in the subject index
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '16

31 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14689 Michael Kuhn <mik(a)adminkuhn.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mik(a)adminkuhn.ch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8897] Optional GnuPG encryption of outgoing emails
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '16

30 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8897 --- Comment #42 from Mirko Tietgen <mirko(a)abunchofthings.net> --- Working on this. Ported the template to Bootstrap, was broken before. Struggling with PGP design flaws. If this is supposed to work without any knowledge on the librarian side, there needs to be a way to prevent people from "stealing a patrons identity". Right now, patron uploads key, key will be used to encrypt emails to patron. However, the connection 'patron' => 'key' is done by gpg: - patron uploads public key - (if previous key for email address exists, it is deleted) - key is stored in gpg (keyring of the koha system user) Let's say an attacker generates a key pair with patron's email address in the UID and uploads it to the attacker's own user account. Patron's old key gets deleted, the new one is used for patron's account. Patron will find out once they cannot open their emails from the library. If the attacker managed to get the email(s) up to this point, they are able to open them, because they got the relevant private key. There needs to be a way to connect patron and key in Koha. The easiest and best for our use case would be to have the public keys in the Koha DB only and encrypt emails using what the DB has, without the gpg key management. Unfortunately that does not seem to be possible at all, at least I could not find it yet. I mean something like "gpg, encrypt text x with public key $public_key_as_string_from_db" Workarounds either need interference on the librarian side or prevent updating patron's public key. I am still hoping to get this working for libraries with zero interest in crypto. I will look into what could be done with some kind of Key ID verification by the patron, but it would be overly complicated compared to storing keys in the db per patron. Sorry, just thinking aloud. If you accidentally receive this transmission and think I am missing something, feel free to interrupt. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14757] Allow the use of Template Toolkit syntax for slips and notices
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '16

30 Jan '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14757 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #11 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- > The existing syntax is quite easy to understand/modify for everybody, but > the TT syntax is not. > I would like to see a discussion on koha-devel to know if everybody agrees > on the removal of the existing syntax, or if we should support both. It would be nice to have all the advantages of TT, but I am also worried that it will make it harder for libraries to change the notices themselves. It currently works quite well, although we have some placeholders that are not well known or not very consistent (<items> vs. <<items.content>> vs. ---- etc.) and need explaining. I looked at the changes on bug 15280 and that looked not too bad. I think key is to have better documentation to explain the change and make it easier to see which variables can be used where and what additional features this will make available. I'd be interested to see how this change will affect the editor - no patch there yet on bug 15277, maybe a screenshot? -- You are receiving this mail because: You are watching all bug changes.

1 0