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

[Bug 25836] New: MARC fields not able to be reordered in basic editor
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25836 Bug ID: 25836 Summary: MARC fields not able to be reordered in basic editor Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl >From bug 7882, it seems that MARC fields should be able to be reordered, however it does not appear to be working. For instance, if I have a record with 3 650 fields and 2 651 fields, I cannot move the 651 fields above the 650 fields. I can rearrange the 650 fields amongst themselves, but that's it. The move icon/hamburger shows on all fields, which leads one to think that all fields can be reordered, when this is clearly not the case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 27421] New: Porting tools/stage-marc-import.pl to BackgroundJob
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '24

21 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27421 Bug ID: 27421 Summary: Porting tools/stage-marc-import.pl to BackgroundJob Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org Hi! I recently started to convert tools/stage-marc-import.pl to use the new BackgroundJobs, because we're using the Plack version, which does not like the old forking implementation. While I've realized now that we can still use the old CGI script by running it directly via the frontend Apache, I'm not very happy with this workaround. So, here is my current first sort-of-working prototype: https://github.com/Koha-Community/Koha/compare/master...domm:MARCImporter Before I continue my work, I'd really appreciate some feedback if what I'm doing makes sense and matches your general plans. Obviously there is still a lot missing: * Proper feedback after starting the staging process (i.e. a link to the job) * Probably I will also need to check if the job has finished, and present a link to the next step (copy the staged records into the library) (which AFAIK will also need to be converted to BackgroundJobs) I also have a few questions: * Is it neccessary to get the job-size before starting it? If yes, then I assume I'll have to first parse the MARC file to get the job size, throwing the results away (and this might not work, because we want to do the parsing in the background in the first place). Or is there an easy way to get the number of records? * When I try to update job_size later, I get an exception (something like "job_size not tested") * Can I actually use BatchStageMarcRecords in BackgroundJob? * I see I can pass a batch size to BatchStageMarcRecords. But this will not result in more forking? This is "only" used to fire the progress callback? I'm also not sure if the bug tracker or the dev mailing list is the best place to discuss my questions? Anyway, looking forward to some feedback! Greetings, domm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 136

[Bug 31719] New: Course name should enforce non-white-space character requirement
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '24

20 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31719 Bug ID: 31719 Summary: Course name should enforce non-white-space character requirement Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org While a course name is required on a course reserve, if that field is populated with a space, Koha accepts it as having a name, but there's no further way to get back to that course or interact with it afterwards since the only link is via name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28981] New: Add a syspref for marking items as unavailable in Z3950Responder
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28981 Bug ID: 28981 Summary: Add a syspref for marking items as unavailable in Z3950Responder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Proposal: 1 - Add a new system preference "Z39ResponderUnavailable" 2 - Similar to 'OpacHiddenItems' this will accept a list of column/value pairs 3 - Update Koha::Z3950Responder::Session::add_item_status to check the preference and mark item as unavailable 4 - Item status message will be pulled from Z3950_STATUS authorized value list -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35254] New: Adding files to basket from a staged file uses wrong inputs for order information when not all records are selected
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35254 Bug ID: 35254 Summary: Adding files to basket from a staged file uses wrong inputs for order information when not all records are selected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 32166 fixed the issue of items and inputs not matching up for item level details, however, the problem still exists for order level information To recreate: 1 - Find a vendor in acquisitions 2 - Create or find an open basket 3 - Add to basket form a new file 4 - Stage file and add to basket 5 - Select the second record in the list 6 - Enter price info 7 - Save (don't forget, you need to set item type in the second tab) 8 - The order has no price info! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 24161] New: Late orders improvements - keeping track of claims
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '24

18 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24161 Bug ID: 24161 Summary: Late orders improvements - keeping track of claims Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org * Allow multiple claim dates to be associated with an individual order line * Show multiple claim dates against an order line in the late orders page * Show multiple claim dates against an order line in the basket page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 102

[Bug 31011] New: Make hold reminders respect patron's language
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '24

17 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31011 Bug ID: 31011 Summary: Make hold reminders respect patron's language Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When running misc/cronjobs/holds/holds_reminder.pl it looks like borrowers.lang is not respected. The only code I can see that relates to language is this: # FIXME What if we don't want to default if the translated template does not exist? my $template_exists = Koha::Notice::Templates->find_effective_template( { module => 'reserves', code => $lettercode, branchcode => $branchcode, lang => 'default', } ); As far as I can see, the "default" template is always used? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30733] New: Simplify translatable strings
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '24

15 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30733 Bug ID: 30733 Summary: Simplify translatable strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr A.K.A "We must be nicer with translators 2" (follow-up of bug 29602) It's the same simple idea that worked well without issues: Add in templates to not have anymore translatable strings like %sEnter a new purchase suggestion%s %sPurchase suggestions%s &rsaquo; %s%s%sKoha online%s catalog git is a great help to review this patch. Don't use the bugzilla diff view. Apply the patch and use: git show --color-words=. Now you will see just the added You can search for and go one by one to check that the opening and closing tags match and that there is no typo. Then the same with I already did that though, so you might want to spare pressing the "n" (next) key 1300 times (684 x 2) --- This patch has been made by searching in the translation platform for "%s" and inspecting the 2300 strings containing it to find those that are terrible to translate: those with tons of %s which are a concatenation of independent strings. Mainly the IFs in template produce these abominations. bug 29602 focused on CASE statement. This is an attempt for all the rest. Except for CSV templates and page <title> tags because can't be used there. Some less terrible strings have been skipped due to lack of time. --- I tried to think about right to left languages in cases like Confirm deletion of subfield [%- tagsubfield | html -%] I included the variable tagsubfield in the so there will be a %s in the translatable string which should allow to invert the order when translating to be RTL. And also I included semicolons in the when the context allows for a translated version with the semicolon on the left to make sense. If the context has a related thing just after on the same line (on the right) to the string, then I didn't include the semicolon to leave it "pointing" at the right thing. Even though that's wrong, but we can't swap the phrases. caveat: I don't have any experience in translating RTL in Koha so I'm not sure if these things help. And I just noticed we have an RTL CSS that might actually swap stuff. If that's the case, the fact that I left the semicolon outside the might not be an issue because it should end up swapped right? --- There are a few fixes like Payment[% ELSE %]Transaction[% END %] type: </label> ↓ Payment type[% ELSE %]Transaction type[% END %] type: </label> because having "type" separated removes the context and it locks the word order as same as English. Which makes this string not possible to correctly translate in French, Spanish and Esperanto for example. --- There is a double , it looks like: Author(s) This is expected. There was already one spanning (ha ha) a few lines and I needed another one just for the string on this line. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 147

[Bug 30872] New: Table on claims.tt ( missing issues table ) should be column configurable
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '24

14 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30872 Bug ID: 30872 Summary: Table on claims.tt ( missing issues table ) should be column configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 30039 adds another column to an already large table in claims.tt. That table should be column configurable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21322] New: process_message_queue.pl --type should take an argument
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '24

14 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21322 Bug ID: 21322 Summary: process_message_queue.pl --type should take an argument Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz If you run process_message_queue.pl -h you get this, among other things: -t --type: If supplied, only processes this type of message ( email, sms ) But if you try to use --type like this: process_message_queue.pl -v --type=sms" <instance> You get this error: Option type does not take an argument This is because the setup of the type argument is wrong. This: 't|type' => \$type, should be this: 't|type:s' => \$type, -- You are receiving this mail because: You are watching all bug changes.

1 19