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

[Bug 36148] Move CSRF check code outside of CGI->new
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '24

19 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36148 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36358 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36358 [Bug 36358] Typo in errorpage.tt: requets -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10060] Allow adding a branch parameter to the web-based self check to indicate library its used at
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10060 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #26 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Brannon from comment #23) > Then we need to do something like allow the library to navigate their self > check to /cgi-bin/koha/sco/sco-main.pl?branch=BRANCHCODE, which would tell > the page to login to the self check with the credentials from their page. > > AutoSelfCheckAllowed set to allow, but having nothing filled in for > AutoSelfCheckID or AutoSelfCheckPass could be the queue for Koha to check > for credentials under the branch, if specified in the URL. > > Thoughts? Locally we use /cgi-bin/koha/sco/sco-main.pl?branch=BRANCHCODE and then add a hidden input to each operation after that to include the branch. We also have AutoSelfCheckID and AutoSelfCheckPass as well still, but we suffix it with a branchcode so that each branch can have its own particular user and password. Nick's POC is interesting though. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 --- Comment #19 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- It's been a long time - maybe I was worried that the field might be locked for manual input if the value is not linked to a vendor? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23540] New: Gender 'N' is not translatable
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23540 Bug ID: 23540 Summary: Gender 'N' is not translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Patrons of type 'I' (institution) automatically get their sex/gender set to 'N' (which is short for "None"), but the 'N' is not translatable and actually shows up in the patron details page. Relevant code in memberentrygen.tt: [% IF ( I ) %]<input type="hidden" name="sex" value="N" />[% END %] The template code for showing the gender text should be unified into single included file, instead of spread over multiple places like: koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: [% IF ( patron.sex == 'F' ) %]Female[% ELSIF ( patron.sex == 'M' ) %]Male[% ELSE %][% patron.sex | html %][% END %] koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-brief.tt: [% IF ( patron.sex ) %]<li><span class="label">Gender:</span>[% IF ( patron.sex == 'F' ) %]Female[% ELSIF ( patron.sex == 'M' ) %]Male[% ELSE %][% patron.sex | html %][% END %]</li>[% END %] -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 21314] New: Koha enforces 3 character password length even if RequireStrongPassword is disabled
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21314 Bug ID: 21314 Summary: Koha enforces 3 character password length even if RequireStrongPassword is disabled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 18298 added the option to enforce password complexity *if* the new system preference RequireStrongPassword is enabled. However, it appears that the code defining the minimum number of characters was not put under control of this preference and thus Koha enforces a minimum password length of 3 even if RequireStrongPassword is disabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36349 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36349 [Bug 36349] Login for SCO/SCI broken by CSRF -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36102] Protect login forms from CSRF attacks
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36102 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36349 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36349 [Bug 36349] Login for SCO/SCI broken by CSRF -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12771] Enhancement to manage more than 3 levels of overdue notice
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12771 Lisette Scheer <lisette.scheer(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette.scheer@bywatersolut | |ions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33262] New: When an ordered record is deleted, we lose all information on what was ordered
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33262 Bug ID: 33262 Summary: When an ordered record is deleted, we lose all information on what was ordered Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu Blocks: 10758 I am moving this out from bug 10758 that was filed for the display issue. But that is actually only the symptom, while we are actually facing a data loss issue. Libraries need to be able to account for the money they spent even after the items and records have been removed from their collection. At the moment we lose the connection between order and bibliographic record when the record is deleted: -- -- Table structure for table `aqorders` -- DROP TABLE IF EXISTS `aqorders`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `aqorders` ( `ordernumber` int(11) NOT NULL AUTO_INCREMENT COMMENT 'primary key and unique identifier assigned by Koha to each line', `biblionumber` int(11) DEFAULT NULL COMMENT 'links the order to the biblio being ordered (biblio.biblionumber)', [...] CONSTRAINT `aqorders_ibfk_2` FOREIGN KEY (`biblionumber`) REFERENCES `biblio` (`biblionumber`) ON DELETE SET NULL ON UPDATE CASCADE, We do have the information about the deleted record and the items, but we need to preserve the link between order and deleted record in some way. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10758 [Bug 10758] Show bibliographic information of deleted records in acquisitions -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 --- Comment #18 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- I think this is still really important, but the patches no longer apply as is. As for fallbacks mentioned by Katrin, looking at the code it looks like it does just fallback to the value whenever a vendor record isn't found.. is that not enough? -- You are receiving this mail because: You are watching all bug changes.

1 0