March 2024 - Koha-bugs - lists.koha-community.org

[Bug 15461] Add staff equivalent for OpacLocationOnDetail
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #8 from Lucas Gass <lucas(a)bywatersolutions.com> --- Created attachment 162980 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=162980&action=e… Bug 15461: Add StaffLocationOnDetail system preference -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15461] Add staff equivalent for OpacLocationOnDetail
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 1993] Task Scheduler Needs Re-write
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993 Maude <maude.boudreau(a)collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maude.boudreau(a)collecto.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36250] New: Add preservation.js to Makefile
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36250 Bug ID: 36250 Summary: Add preservation.js to Makefile Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Like the ERM module, the Preservation module is built in Vue and the compiled assets need to be included in the Makefile for the Debian package to include them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #15 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Emily Lamancusa from comment #14) > (In reply to Christopher Brannon from comment #13) > > Could you keep the old syntax functional for existing users and give them a > > version or two to update their notices/slips? Maybe only change the default > > notices that have not been modified from install? It seems reasonable to > > give existing users time to clean up their own notices with the new tools. > > That way, if there are any complications or something missed, they some > > wiggle room before the old stuff goes away. > > Yes, that's basically the idea. The old syntax will still be fully > functional for now. We have Bug 15279 to remove the functionality > eventually, but that bug is blocked and won't happen until after we update > the installation defaults (this bug), create a reference guide (bug 34472), > and improve the notice editor (bug 15277) so that users actually have the > tools to make good use of Template Toolkit syntax. > > The questions I'm trying to get at now are: > 1) If a library hasn't modified a particular notice from install, should we > still make them responsible for updating it themselves, or should we update > it automatically in that case (since it should be relatively straightforward > to check for the old default template and replace it with the new default > template)? > > 2) If we do update it automatically, should we do it now, or wait until the > old syntax actually becomes nonfunctional? 1) You should update it automatically if it hasn't been modified. 2) Right away. This gives people more exposure to how it is used. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #14 from Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> --- (In reply to Christopher Brannon from comment #13) > Could you keep the old syntax functional for existing users and give them a > version or two to update their notices/slips? Maybe only change the default > notices that have not been modified from install? It seems reasonable to > give existing users time to clean up their own notices with the new tools. > That way, if there are any complications or something missed, they some > wiggle room before the old stuff goes away. Yes, that's basically the idea. The old syntax will still be fully functional for now. We have Bug 15279 to remove the functionality eventually, but that bug is blocked and won't happen until after we update the installation defaults (this bug), create a reference guide (bug 34472), and improve the notice editor (bug 15277) so that users actually have the tools to make good use of Template Toolkit syntax. The questions I'm trying to get at now are: 1) If a library hasn't modified a particular notice from install, should we still make them responsible for updating it themselves, or should we update it automatically in that case (since it should be relatively straightforward to check for the old default template and replace it with the new default template)? 2) If we do update it automatically, should we do it now, or wait until the old syntax actually becomes nonfunctional? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #13 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Emily Lamancusa from comment #12) > One more thing to consider: do we just update the default text in > sample_notices.yml for new installations at this point, or do we also > include dbrevs for existing installations that use the default notice text? > > Normally, we don't update the default notice text for existing installations > unless there is a breaking change. However, since the goal is to eventually > deprecate the old syntax, which will be a breaking change, it might be > better to update the defaults on both new and existing installations > together... It will be unavoidable for libraries with customized notices to > need to update their own notices eventually. However, I'm sure there are > libraries who rely on the default notices and may not be familiar with > customizing their notices at all, and I could see it being a major issue if > a large number of their notices, which they haven't touched, stop working. > > One could argue that we should wait until we actually introduce the breaking > change to update the default notice text on existing installations, but IMO > it makes more sense to do it now rather than tracking down what the default > used to be sometime later. (Granted, we will still probably miss some > installations that have older "default" versions of notices whose defaults > have already been changed in the past, but I still think we should prevent > problems as much as we can now.) > > The downside is that it makes the current task harder, and introduces a > chance of bugs/regressions...but I still think it's worth it to avoid even > more difficulties later. Could you keep the old syntax functional for existing users and give them a version or two to update their notices/slips? Maybe only change the default notices that have not been modified from install? It seems reasonable to give existing users time to clean up their own notices with the new tools. That way, if there are any complications or something missed, they some wiggle room before the old stuff goes away. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #12 from Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> --- One more thing to consider: do we just update the default text in sample_notices.yml for new installations at this point, or do we also include dbrevs for existing installations that use the default notice text? Normally, we don't update the default notice text for existing installations unless there is a breaking change. However, since the goal is to eventually deprecate the old syntax, which will be a breaking change, it might be better to update the defaults on both new and existing installations together... It will be unavoidable for libraries with customized notices to need to update their own notices eventually. However, I'm sure there are libraries who rely on the default notices and may not be familiar with customizing their notices at all, and I could see it being a major issue if a large number of their notices, which they haven't touched, stop working. One could argue that we should wait until we actually introduce the breaking change to update the default notice text on existing installations, but IMO it makes more sense to do it now rather than tracking down what the default used to be sometime later. (Granted, we will still probably miss some installations that have older "default" versions of notices whose defaults have already been changed in the past, but I still think we should prevent problems as much as we can now.) The downside is that it makes the current task harder, and introduces a chance of bugs/regressions...but I still think it's worth it to avoid even more difficulties later. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36262] New: Under an item's status, provide the shelving location drop down menu
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36262 Bug ID: 36262 Summary: Under an item's status, provide the shelving location drop down menu Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lindsayfuchs(a)countyofplumas.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 162859 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=162859&action=e… mentioned item page and status area When you go home -> search and click on the title of an item -> it gives you several options on the left hand side including "item" (see attached, side labeled "image A" for clarification). Under statuses, it currently shows (among other things) Lost Status, Damaged Status, and Withdrawn Status (see attached, side labeled "image B" for clarification.) I want to know if I can get the "c - Shelving location (drop down menu)" to show there too with the "set" option button. This way people who do not have cataloging permission for items would still be able to change where items are shelved. I'm also wondering if for the larger picture there would be a way to pick which of the fields on the edit item page can be shown there - home/current branch, price, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kyle(a)bywatersolutions.com |emily.lamancusa@montgomeryc | |ountymd.gov --- Comment #11 from Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> --- All notices that still use the old bespoke syntax in their default notice text now have a linked bug on this omnibus. I grouped similar notices together in some cases when I felt it made sense, though they can be further split out in dependent bugs if needed. (Reminder that here we are focused only on updating the default notice text and making sure that all notices CAN be rendered with Template Toolkit, not on documentation (see bug 34472) or deprecating the existing functionality (bug 15279)) Many of the notices should be largely trivial to update to Template Toolkit syntax - the underlying code is already there, and it's just a matter of replacing a few lines in the sample notice itself. However, there are some that will need work on the underlying code before they can be recreated with Template Toolkit. Should be trivial to update: Bug 35925 - Port default purchase suggestion notices to Template Toolkit Bug 36020 - Port default recall notices to Template Toolkit Bug 36106 - Port default PREDUE and DUE notices to Template Toolkit Bug 36110 - Port default OVERDUES_SLIP to Template Toolkit syntax Bug 36112 - Port default CHECKOUT_NOTE notice to Template Toolkit syntax Bug 36113 - Port default RENEWAL notice to Template Toolkit syntax Bug 36114 - Port default TRANSFERSLIP notice to Template Toolkit syntax Bug 36124 - Port default Article Request notices to Template Toolkit syntax Bug 36125 - Port default HOLD_SLIP notice to Template Toolkit syntax Bug 36126 - Port default HOLD notice to Template Toolkit syntax Bug 36127 - Port default HOLDPLACED and HOLD_CHANGED notices to Template Toolkit syntax Bug 36253 - Port default acquisition notices to Template Toolkit syntax Bug 36255 - Port default OPAC_REG_VERIFY notice to Template Toolkit syntax Bug 36256 - Port default MEMBERSHIP_EXPIRY notice to Template Toolkit syntax Bug 36257 - Port default DISCHARGE notice to Template Toolkit syntax Bug 36259 - Port default SERIAL_ALERT notice to Template Toolkit syntax Bug 36260 - Port default PROBLEM_REPORT notice to Template Toolkit syntax Need work on the underlying code: Bug 15283 - Switch default ISSUEQSLIP notice to Template Toolkit Bug 15284 - Switch default ISSUESLIP notice to Template Toolkit Bug 36107 - Port default DUEDGST and PREDUEDGST notices to Template Toolkit Bug 36109 - Port default ODUE notice to Template Toolkit Bug 36254 - Port default PASSWORD_RESET and STAFF_PASSWORD_RESET notices to Template Toolkit syntax Bug 36258 - Port default SHARE_ACCEPT and SHARE_INVITE notices to Template Toolkit syntax -- You are receiving this mail because: You are watching all bug changes.

1 0