February 2017 - Koha-bugs - lists.koha-community.org

[Bug 17479] New: REST API: Save information on owner access
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '20

17 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17479 Bug ID: 17479 Summary: REST API: Save information on owner access Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org There are two ways of accessing a resource via REST API; either: - you have the required permission - you do not have the permission but you are owner of the object, e.g. you want to GET your own patron information In many cases we want to perform additional operations if the user is accessing his own object. Usually this additional operation is checking a system preference. Example: Patron wants to update his own patron information via REST API. We have to check OPACPatronDetails system preference for this. If it is on, we should forward the changes for approval from a librarian. Currently, in controller, we can check this opac-like access by checking that the user does not have permissions and that the patron he is accessing is himself. This would require another haspermission() call. Instead, we could set a flag into $c->stash in Koha/REST/V1.pm in the case of ownership access. After this, in controller, we only need to check $c->stash for this flag. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 16147] New: OpacItemLocation and not for circulation Item types
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '20

15 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16147 Bug ID: 16147 Summary: OpacItemLocation and not for circulation Item types Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ed.veal(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If you set the OpacItemLocation to anything other than "Call number only" the call number is repeated on the Location line for all items with item types that don't circulate. <xsl:if test="items:itemcallnumber != '' and items:itemcallnumber and $OPACItemLocation='callnum'"> [<span class="LabelCallNumber">Call number: </span><xsl:value-of select="items:itemcallnumber"/>]</xsl:if> <xsl:if test="items:itemcallnumber != '' and items:itemcallnumber"> [<span class="LabelCallNumber">Call number: </span><xsl:value-of select="items:itemcallnumber"/>]</xsl:if> Ed -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 16123] New: Display budget hierarchy in the budget dropdown menu used when placing a new orde
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '20

13 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16123 Bug ID: 16123 Summary: Display budget hierarchy in the budget dropdown menu used when placing a new orde Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: francois.charbonnier(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When placing a new order, the budget dropdown will display the budget hierarchy. TEST PLAN : 1. Go to the Administration module 2. Add a new budget (ie : Budget 2016) 3. Add a fund to this budget (ie : Book) 4. Add a child fund (ie : Adult fiction) You will have this hierarchy : Budget 2016 |____ Book |_____ Adult fiction 5. Go to the Acquisition module 6. Select a vendor and create a new basket 7. Place an order 8. Check the budget dropdown menu BEFORE PATCH Book Adult fiction AFTER PATCH Book Adult fiction -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 17896] New: Enabling syspref 'BakerTaylorEnabled' causes software error
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '20

13 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17896 Bug ID: 17896 Summary: Enabling syspref 'BakerTaylorEnabled' causes software error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org This error: Undefined subroutine &CGI::Compile::ROOT::home_vagrant_kohaclone_opac_opac_2dreadingrecord_2epl::image_url called at /home/vagrant/kohaclone/opac/opac-readingrecord.pl line 125. is triggered when I enable BakerTaylorEnabled and look at my reading history on the OPAC because subroutines it needs aren't imported until after they are called. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 17611] New: Searching for orders uses misleading column name " Pending order"
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '20

13 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17611 Bug ID: 17611 Summary: Searching for orders uses misleading column name "Pending order" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org Steps to reproduce: 1) Open the Acquisition module 2) At the top of the page click "Orders search" 3) Fill-in a book title that has been already received and submit the form 4) Title is found displaying (among others) these columns: - Quantity received - Pending order The Pending order is NOT pending, in fact. The header should be renamed to "Quantity ordered". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 16719] New: LDAP: Using empty strings as 'failsafe' attribute mapping defeats database constraints
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16719 Bug ID: 16719 Summary: LDAP: Using empty strings as 'failsafe' attribute mapping defeats database constraints Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: oliver.bock(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Created attachment 52316 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52316&action=ed… Patch: proper NULL mapping LDAP attributes with empty values are currently mapped as empty strings, which is described as 'failsafe'. This defeats the existing database constraints (NULL and UNIQUE) without an apparent need. If some kind of empty default is required, it should be set in the mapping config itself, not the code. Please note that this is not just a semantic issue since mapping empty LDAP values as an empty string does indeed cause a constraint violation (read: database error, hence our severity) when such an attribute bears a UNIQUE constraint. This is due to the fact that an empty string is an actual value validated by the constraint (NULL isn't). I don't know the reasoning behind the empty-string mapping but should a NULL-mapping have been the original intention then please note that this behavior is database-dependent. The correct way to map NULL in a database-agnostic way is to use "undef" (see my patch). Thanks -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 15860] New: Alias missing for /plugin on packages
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15860 Bug ID: 15860 Summary: Alias missing for /plugin on packages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Created attachment 48235 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48235&action=ed… Broken image There is an alias missing on the packages-shipped apache templates. It prevents some things to show on the UI. To test: - Enable the plugins - Install libmarc-lint-perl - Install the MARC checker plugin (https://github.com/bywatersolutions/koha-plugin-marc-checker) - Run the plugin => FAIL: There's a broken image link (see attachment) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 16758] New: Caching issues in scripts running in daemon mode
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '20

02 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16758 Bug ID: 16758 Summary: Caching issues in scripts running in daemon mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org As L1 cache does not have expiration mechanism, scripts running in daemon mode (rebuild_zebra.pl -daemon, sip server ?, ...) would not be aware of any possible changes in the data being cached in Koha::Cache. While adding expiration functionality to Koha::Cache would be pretty simple, I guess we don't really want to expire things by default after a given amount of seconds, that would not be good for overall performance; default expiration time for L2 = memcached is infinite (intentionally). Note that it's also infinite for L2 = Cache::Memory - probably not intentional, more likely that's because this code # Default cache time for memory is _always_ short unless it's specially # defined, to allow it to work reliably in a persistent environment. my $cache = Cache::Memory->new( 'namespace' => $self->{'namespace'}, 'default_expires' => "$self->{'timeout'} sec" || "10 sec", ); doesn't work as advertised. That might be a problem for plack + Cache::Memory setups - hopefully nobody uses such weird combos. Anyway, that belongs to the separate bug report. I wonder what would be a best approach for solving this issue for perpetually running scripts? Maybe just adding a function to Koha::Cache which flushes L1 cache (but not more often then each 10 | 20 | 30 seconds), and call it in rebuild_zebra.pl etc. daemon loop - ? -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 15967] New: Print notices are not generated if the patron cannot be notified
by bugzilla-daemon＠bugs.koha-community.org 24 Feb '20

24 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15967 Bug ID: 15967 Summary: Print notices are not generated if the patron cannot be notified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Notices Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Regression introduced by bug 14133, see but 14133 comment 13. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 17954] New: Remove the sql code from the smart-rules.pl administrative script
by bugzilla-daemon＠bugs.koha-community.org 15 Feb '20

15 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17954 Bug ID: 17954 Summary: Remove the sql code from the smart-rules.pl administrative script Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 17855 The purpose of this bug is to remove the sql code from the smart-rules.pl administrative perl script thereby aligning it with the Koha coding guidelines. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17855 [Bug 17855] Updated Koha web installer and new onboarding tool feature to guide users through setting up Koha -- You are receiving this mail because: You are watching all bug changes.

1 8