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

[Bug 15562] Make Koha more suitable for shared hosting with plack
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562 --- Comment #33 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 50716 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=50716&action=ed… [SIGNED-OFF] bug_15562: Removed Koha::Cache->get_instance() There should be no cache singleton, full stop. If Koha is to move away from .pl scripts that is. As an interim measure Koha::Cache->get_instance() is replaced with C4::Context->cache, in the vein of C4::Context->memcached. In that respect it will continue to work in the singleton-ish way if context is used as a singleton, but supports cache-per-context. Koha::Handler::Plack->app_per_host() cache sysprefs using Context memcached. https://bugs.koha-community.org/show_bug.cgi?id=15562 Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15562] Make Koha more suitable for shared hosting with plack
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562 --- Comment #32 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 50715 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=50715&action=ed… [SIGNED-OFF] bug_15562: Multi-host helper for plack installations Sort of an apocalypse * C4::Context->new() must be called with at least config file param. If you want current context, call C4::Context->current(). C4::Context->some_method() will still work as is. * Koha::Database->new_schema() now takes optional context param. * C4::Context->set_context() and restore_context() are synched with database set_schema() and restore_schema(). Created run_within_context() that wraps set_context() and restore_context() around code. * Created Koha::Handler::Plack* to facilitate running same code within different (database) contexts. * This initial version does not run with memcached turned on. Next patch will correct that. https://bugs.koha-community.org/show_bug.cgi?id=15562 Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15562] Make Koha more suitable for shared hosting with plack
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562 --- Comment #31 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 50714 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=50714&action=ed… [SIGNED-OFF] bug_15562: Revert "Bug 13690: use Koha::Schema only when it's needed" This reverts commit c52bc9756a5fa1e4f6bba7ce5c58124f150c5efc. I don't see any place where we would use KOha::Database without wanting Koha::Schema. require Koha::Schema interferes with some plack setups - for some reason it calls C4::Context->import() even when C4::Context is already used. Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15562] Make Koha more suitable for shared hosting with plack
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #49664|0 |1 is obsolete| | Attachment #49665|0 |1 is obsolete| | Attachment #50702|0 |1 is obsolete| | Attachment #50703|0 |1 is obsolete| | --- Comment #30 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 50713 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=50713&action=ed… [SIGNED-OFF] bug_15562: Use do() rather than system() to execute updatedatabase.pl from installer.pl That way: * no external process is spawned * code executes in the same perl process, which is required for plack multi-site I have a dream. A dream that one day all code from .pl's will be in some .pm's. Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15562] Make Koha more suitable for shared hosting with plack
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15126] REST API: Use newer version of Swagger2
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15126 --- Comment #39 from Julian Maurice <julian.maurice(a)biblibre.com> --- (In reply to Jonathan Druart from comment #38) > (In reply to Julian Maurice from comment #32) > > Created attachment 50142 [details] [review] [review] > > Bug 15126: Update patron definition > > Julian, I think we need tests to make sure the swagger file will be always > up-to-date with the DB structure. Any ideas how we could do that? An easy solution would be to parse the spec file with Swagger module, and for each path check that the keys are the same that the corresponding DB table. But what if some paths return more (or less, or different) keys than the corresponding DB table (or if there is no corresponding DB table) ? A proper solution would be to call each path and check that the keys in the response match with the spec, but it has to be done each time a path is added -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13381] RDA: 245 field changes in XSLT
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=16352 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13381] RDA: 245 field changes in XSLT
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381 --- Comment #40 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #37) > Hi Ian, can you please file this as a separate bug report linked to this one? Ian and Katrin: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16352 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13381] RDA: 245 field changes in XSLT
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381 --- Comment #39 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Ian Bays from comment #36) > It seems that the change in the xslt to put span around subfields c and h > has removed the space that was generated between the subfields. > In koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl there > is an: > <xsl:text> </xsl:text> > at line 125 in the otherwise clause that spaces out the subfields. The two > that were singled out do not have this. Adding them back in within the > <span> achieves the normal, desired spacing. I also have observed this... I suppose I can open a bug for it once I finish a few other tasks... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13381] RDA: 245 field changes in XSLT
by bugzilla-daemon＠bugs.koha-community.org 26 Apr '16

26 Apr '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381 --- Comment #38 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Winona Salesky from comment #35) > The order in the for-each does not determine the order of the output. > Subfields are output in the order they appear in the marc record. They are > in alphabetical order in the for-each, purely for convenience sake. > > -Winona > Right you are. I must have been thinking of "subfieldSelect" which does rely on the order of the string of codes. My bad! -- You are receiving this mail because: You are watching all bug changes.

1 0