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

[Bug 35298] New: Flatpickr makes focus handler in dateaccessioned plugin useless
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35298 Bug ID: 35298 Summary: Flatpickr makes focus handler in dateaccessioned plugin useless 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See also bug 31665. Remove focus handler from dateaccessioned plugin. The onOpen from flatpickr has control now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 35276] New: Posting a suggestion crashes on Unknown column 'auth_forwarded_hash'
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35276 Bug ID: 35276 Summary: Posting a suggestion crashes on Unknown column 'auth_forwarded_hash' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface 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 Seen in production on 22.11. Still investigating further a bit. May affect severity later. It seems that the Auth.pm originating auth_forwarded_hash is passed into a Koha Objects search. So it should be deleted before that point. L426 my @suggestions = Koha::Suggestions->search_limited($search_params)->as_list; Will still be adding comment(s). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 35012] New: Cataloguing plugins (value builder) fired twice on create items form
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35012 Bug ID: 35012 Summary: Cataloguing plugins (value builder) fired twice on create items form Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org When adding items on received orders (or on created orders) the value builder buttons fire twice when clicked. This could lead to f.e. inventory numbers increased by 2 or other unwanted behaviors to rebuild this behavior: a) build a new basket + order line using "item create on placing an order" b) in the item creation dialog please use the webbrowsers dev tools to analyze the [...] button next to subfield d (Date acquired) and inspect the events that get fired by clicking c) notice the Clicktag_952_subfield_d_* event gets fired twice. This also happens using: "item create on receiving an order" or other cataloguing plugins. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 35244] New: AcqItemSetSubfieldsWhenReceived not working after upgrade
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35244 Bug ID: 35244 Summary: AcqItemSetSubfieldsWhenReceived not working after upgrade Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org AcqItemSetSubfieldsWhenReceived not working after upgrade to 23.05 Item fields are not updated when receiving items in acquisition -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 34919] New: Unimarc 106 182
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34919 Bug ID: 34919 Summary: Unimarc 106 182 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org The search by "physical representation" does not work if the subfields 182 of the Unimarc field are filled in. It works if you fill out 106, but these subfields are outdated. 106 CODED DATA FIELD: TEXTUAL RESOURCE - FORM OF ITEM Field Definition This field contains coded data relating to the form of an item textual unmediated resources (i.e., no mediation device is required to use or perceive the textual content of the resource). Occurrence Optional. Not repeatable. Indicators Indicator 1: blank (not defined) Indicator 2: blank (not defined) Subfield $a Form of resource Item: Coded Data:Medium Designator A one character code indicates the physical medium of the resource item. The following codes are used: d = large print e = newspaper format f = Braille or Moon script g = microprint h = hand-written i = multimedia (e.g. a resource an item in regular print with a microfiche supplement) (obsolete) This code is replaced by field 182 Coded Data Field - Media type, $a/0 code "m"= "multiple media". j = mini-print r = regular print s = electronic (obsolete) This code is replaced by field 182 Coded Data Field - Media type, $a/0 code "b"= "electronic". To be used when resource Item is intended for manipulation by a computer. The resource item may reside in a carrier accessed either directly or remotely, in some cases requiring the use of peripheral devices attached to the computer. This code is not used for items that do not necessarily require the use of a computer (e.g. music compact discs, videodiscs). t = microform (obsolete) This code is replaced by field 182 Coded Data Field - Media type, $a/0 code "c"= "microform". z = other form of material Notes on Field Contents Where the textual material is regular print, the field may contain code 'r' or be omitted altogether. https://cdn.ifla.org/wp-content/uploads/files/assets/uca/unimarc_updates/BI… https://cdn.ifla.org/wp-content/uploads/files/assets/uca/unimarc_updates/BI… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 10958] no need for home link on home page
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10958 --- Comment #13 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Lucas Gass from comment #12) > You're right, it comes down to preference. I am not sure if this even > warrants another new system preference since one can just add to OPACUserCSS: > > #opac-main .breadcrumbs { > display: none; > } > > > Maybe a sys pref is overkill and we should just "RESOLVE - WONT FIX" this > one? Part of me thinks a syspref is overkill, but it must be annoying having to add that to each new instance, so I suppose I'd like to make everyone happy. I suppose I always add the following to OPACUserCSS for every new instance, so maybe we all have different bits and bobs we always add. #logo { display: none; } Previously, I've suggested adding a profile for koha-create that could setup sysprefs in a vendor-specific way. That could be an interesting alternative too... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10958] no need for home link on home page
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '23

15 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10958 --- Comment #12 from Lucas Gass <lucas(a)bywatersolutions.com> --- > Overall, I think this one might just come down to preference, so probably > best to add a system preference. You're right, it comes down to preference. I am not sure if this even warrants another new system preference since one can just add to OPACUserCSS: #opac-main .breadcrumbs { display: none; } Maybe a sys pref is overkill and we should just "RESOLVE - WONT FIX" this one? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10958] no need for home link on home page
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '23

15 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10958 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|aleisha(a)catalyst.net.nz | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10958] no need for home link on home page
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '23

15 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10958 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #11 from David Cook <dcook(a)prosentient.com.au> --- I've never had any complaints about this from any libraries, and personally I like having the "Home" breadcrumb on the home page. Looking around online but not finding anything on this exact topic. I found oregon.gov used in an article on usability, and their Oregon Health Authority section is an example where the breadcrumb isn't shown on some home/landing pages, but I think it looks terrible. Although I think it's terrible because the banner is smaller on pages with the breadcrumb and bigger on pages without it, which makes for an inconsistent look and feel. I think my libraries would complain about content displaying higher on the home page without the breadcrumb and lower on pages with the breadcrumbs, but maybe I'm wrong. Maybe they wouldn't care either way. But I don't think we can 100% remove a visual element that's been present for so long without a way to bring it back. Overall, I think this one might just come down to preference, so probably best to add a system preference. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10958] no need for home link on home page
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '23

15 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10958 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com --- Comment #10 from Lucas Gass <lucas(a)bywatersolutions.com> --- (In reply to Katrin Fischer from comment #9) > With the staff interface redesign we still have the home icon on the start > page, same for the OPAC. > Can we agree to keep or remove? I vote for remove. I always have to hide this with CSS for new instances. Breadcrumbs are a trail back to the homepage and if you are already there I find them useless, redundant, and confusing. -- You are receiving this mail because: You are watching all bug changes.

1 0