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

[Bug 36289] New: Allow automatic item modification by age to set a date field to today's date
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '24

09 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36289 Bug ID: 36289 Summary: Allow automatic item modification by age to set a date field to today's date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be helpful if automatic item modification by age could set a date field to today's date. Example: Age in days: 60 Age field: items.itemlost_on Conditions: items.itemlost=5 Substitutions: items.itemlost=6 items.itemlost_on=Today Or, if you want to update the date accessioned to the first day it was circulating, you could set up a custom damaged status to put items in before they go to circulate: Age in days: 1 Age field: items.itemdamaged_on Conditions: items.itemdamaged=3 Substitutions: items.itemdamaged=0 items.dateaccessioned= Today's date -- 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 09 Mar '24

09 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #10 from Lucas Gass <lucas(a)bywatersolutions.com> --- Created attachment 162982 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=162982&action=e… Bug 15461: perltidy DB update -- 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 09 Mar '24

09 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #9 from Lucas Gass <lucas(a)bywatersolutions.com> --- Created attachment 162981 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=162981&action=e… Bug 15461: Implement StaffLocationOnDetail To test; 1. APPLY patch, updatedatabase, restart services 2. Search for the new system preference 'StaffLocationOnDetail' 3. Read the description and make sure it makes sense. Check that the 'Table settings' link works. 4. By default it should be set to 'below the home library'. 5. Check to make sure that is where it displays. 6. Try 'below the holding library' and 'below both home and holding libraries', making sure each works properly. 7. Try 'on a sperate column', in which case you need to make sure that 'holdings_shelvinglocation' is properly checked under Administration > Table settings 8. Play with other Table settings to make sure they all work as they should. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

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

09 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 09 Mar '24

09 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