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

[Bug 22497] New: '0' width can lead to an infinite loop.
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22497 Bug ID: 22497 Summary: '0' width can lead to an infinite loop. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- > > "Aha... it's the parentheses which are the problem. They're being interpreted as > > regex metacharacters and not literal values!" > > We noticed that there seems to be an infinite loop if the template has some > or all entries with "0" in it (like in default when creating a new > template). Could this be the same cause? Sorry, I just realized that you were referring to the template rather than the layout. Yes, it would be a related problem, but a separate issue. If 'label_width' is 0, then $self->{'width'} will be 0. That means that this condition will be triggered: if (($string_width + $text_attribs->{'llx'}) > $self->{'width'}) And because $self->{'width'} is 0, then the following condition would never feasibly be triggered: if (($string_width + $text_attribs->{'llx'}) < $self->{'width'}) And this condition is the only thing that can stop the infinite loop. Really the line wrapping code looks like it would benefit from a re-write. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 21508] New: lost item phrase is repeated on pay fines page, when a patron is charged after an item is changed to lost
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '24

08 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21508 Bug ID: 21508 Summary: lost item phrase is repeated on pay fines page, when a patron is charged after an item is changed to lost Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org The preference system WhenLostChargeReplacementFee = charge On the tab fines, pay fines (/members/pay.pl), when a patron is charged automatically because an item he has borrowed is changed to lost status, the test repeats "lost iem" twice in the column description : Lost item , Lost Item + Title -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21507] New: Decimal separators issues in patrons payments/fines, simplified
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '24

08 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21507 Bug ID: 21507 Summary: Decimal separators issues in patrons payments/fines, simplified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr This is a reboot of bug 12310 with simpler specs. kidclamp and paul_p discussed about it at the KohaCon and they would push for simpler requirements than the ones that I got at the 2018 march hackfest. And after some discussions on #koha, it seems that it should be acceptable :) == Specs == - allow only one separator, the one from CurrencyFormat - if some libraries really need supporting multiple ones, it should be another patch, don't hesitate to open a bug to talk about this - do not handle thousands separator - block form submission if the format is wrong == resources: some of the latest IRC discussions == http://irc.koha-community.org/koha/2018-10-05#i_2078324 http://irc.koha-community.org/koha/2018-10-05#i_2078377 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 20819] New: GDPR: Add a consent field for processing personal data
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '24

06 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20819 Bug ID: 20819 Summary: GDPR: Add a consent field for processing personal data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com See 18081 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 106

[Bug 17810] New: Add a button to navigate between notices
by bugzilla-daemon＠bugs.koha-community.org 31 May '24

31 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17810 Bug ID: 17810 Summary: Add a button to navigate between notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 58404 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=58404&action=ed… The small window in the upper left circled in red It will be interessting to have the option to navigate directly between notices (previous/next). The option already exist in catalog module. Maybe, it can be added into another module ? 1)From the start, go to lists 2)Take "public list" and enter a search 3)Select any notice to have all his details on screen 4)Observe that you cannot reach another notice of your search without making "previous page" After some searches here, the patch doesn't seems to exist for that. Thanks, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 20358] New: Add unitprice_tax_included on report spent.pl
by bugzilla-daemon＠bugs.koha-community.org 31 May '24

31 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20358 Bug ID: 20358 Summary: Add unitprice_tax_included on report spent.pl 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: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, On acqui/spent.pl, it would be nice to have a new column for unitprice_tax_included. Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 19535] New: Notice (Available) for suggestion is not send at the right time
by bugzilla-daemon＠bugs.koha-community.org 31 May '24

31 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19535 Bug ID: 19535 Summary: Notice (Available) for suggestion is not send at the right time Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Koha has a notice template for notifications to be sent out to the patron once a suggestion gets available (AVAILABLE). But the notification is send to the patron who has made the suggestion directly when the suggestion has been receive. This notification should be send when the status of the record item is available. 1) Create suggestion in OPAC; 2) Accept suggestion in Staff; 3) Order suggestion in acquisitions; 4) Close basket; 5) Receive order; >The mail is generate for the patron who make the suggestion but the item is not ready to circulate. It would be nice to have an email for the reception and an email to indicate that the item is really ready to circulate, considering the status of the document. Regard, Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 19733] New: Navigation in the pages result with cn_browser.pl is setting in a field
by bugzilla-daemon＠bugs.koha-community.org 31 May '24

31 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19733 Bug ID: 19733 Summary: Navigation in the pages result with cn_browser.pl is setting in a field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, When cn_browser.pl is setting in a field and we edit a record for browse the call number, we can't navigate between the pages results. It would be usefull if this plugin could works like in the call numbers browser who we can navigate in the pages result ass well with the arrow in the bottom of the page. Maybe we could have this navigation arrows in the top and te bottom of the pages result. Patrick. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 18034] New: Pseudonym records not found in a research by author
by bugzilla-daemon＠bugs.koha-community.org 31 May '24

31 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18034 Bug ID: 18034 Summary: Pseudonym records not found in a research by author Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 59754 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=59754&action=ed… Page with "see also" links ("Voir aussi :") It's probably a minor bug. If you make a search with this author, your search will normally give you the records linked to the pseudonyms of the name. But in our searches, these pseudonyms records don't appear in the results of an author search even if the links "see also" were created previously. I will take an example that almost all of us will know. The author of Harry Potter wrote under many names : Robert Galbraith, Newt Scamander and Kennilworthy Whisp. All these names are normally linked between them by a "see also" mention. (The link must be done previously during cataloging. Sadly, not so many of us did all this up here.) Here is the way to check if you have links "see also" already created. 1) In an OPAC, make a search with J. K. Rowling 2) Observe that all results are directly related to J. K. Rowling 3) Clic on a book writen by this author (not a movie) 4) Just under the title of the record, you have the mention "author" with a magnifying glass, clic on the magnifying glass 5) You will see all forms the name can take and under we have the "see also" mentions (if created) 6) If they are created, you can clic normally on these names. 7) A page appears with a mention something like "Authorities search results" (we have it in french) 8) In the third column of the board, it's indicated "Bibliographic records", you can clic on the results just under ("x documents") 9) In my particulary case, I took Robert Galbraith for which we have 3 records (maybe they are more) : Career of evil, Silkworm and Cuckoo's calling. 10) If I return to my first results for J. K. Rowling, I cannot see these three books anywhere... Records with a pseudonym name (in the "see also" links) should appear in the record results of an author. Some people here suggest to create a system preference like "IncludeSeeFromInSearches" to find the records in the "see also" links. Thanks, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 22230] New: Make SearchWithISBNVariations search in index keyword
by bugzilla-daemon＠bugs.koha-community.org 31 May '24

31 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22230 Bug ID: 22230 Summary: Make SearchWithISBNVariations search in index keyword Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Hi, the SearchWithISBNVariations system preference does not search for variants in the index keyword (kw, wrdl). It is imperative to use the ISBN index (nb) for this kind of search. It would be nice if this system preference makes it possible to search the ISBN variants in the index keyword as well. Thanks, Patrick -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7