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

[Bug 32316] New: Send invitations to share a list immediately
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '23

24 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32316 Bug ID: 32316 Summary: Send invitations to share a list immediately Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Invitations to share a list (SHARE_INVITE) are sent via the message_queue, so there can be a noticeable delay. It would be nice if we could use the same trick here as for password reset and self registration verification mails, that are sent through message_queue, but processed/sent immediately. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 13976] Sorting search results by popularity is alphabetical
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '23

24 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13976 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|martin.renvoize@ptfs-europe |m.de.rooy(a)rijksmuseum.nl |.com | Status|Signed Off |BLOCKED CC| |m.de.rooy(a)rijksmuseum.nl --- Comment #19 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- QAing -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33331] New: Qwant VIPrivacy is hidding "Share list" link
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '23

24 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33331 Bug ID: 33331 Summary: Qwant VIPrivacy is hidding "Share list" link Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Just recording this here but I don't think we should fix it. If you are using "Qwant VIPrivacy" Firefox extension, you won't see the "Share list" link at the OPAC because of the 'sharelist' class. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19464] New: emailLibrarianWhenHoldIsPlaced email enhancement
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19464 Bug ID: 19464 Summary: emailLibrarianWhenHoldIsPlaced email enhancement Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: karen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com A school library that I'm working with would like the email sent by the preference emailLibrarianWhenHoldIsPlaced to go the library where the hold is placed rather than the admin email address. Sending an email directly to the branch email address would be a really nice option for multibranch systems that want to use this system preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #73 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Jonathan Druart from comment #67) > Not blocker, but noting: > 2. We don't have access to already read notes. Could be added later if > needed. Staff do, patrons do not. Yes, something to consider adding later if needed. Would have to be adjusted on the staff side, as right now, staff have all control as to how long a message sticks around. We would need to probably have some way of hiding the message when read, like we do on the patron side, and then have a way to access read messages on both sides, and then decide how to manage read messages. Again, something for another bug perhaps. This is a good start. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33325] New: UpdateItemLocationOnCheckin message should accurately report when location set to null
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33325 Bug ID: 33325 Summary: UpdateItemLocationOnCheckin message should accurately report when location set to null Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1 - set UpdateItemLocationOnCheckin to "_ALL_: _PERM_" 2 - have an item where items.permanent_location is null but items.location is not null 3 - check your item in, get message that location was updated, including wording "New value: "Blank"" 4 - check your item in the database, confirm location has been set to NULL rather than blank Getting location to have a value with permanent_location is null takes some niche setup to accomplish in the staff interface. See this comment for instructions, but it'd be easier to just set up a test item from the database: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33301#c2 The UpdateItemLocationOnCheckin syspref contains the option to set things to "_BLANK_" at checkin. When that option is used, things are actually set to blank (items.location='') rather than NULL, so in those cases the message *is* accurate. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 24231] New: Create classes to the message that was created with sys pref UpdateItemLocationOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24231 Bug ID: 24231 Summary: Create classes to the message that was created with sys pref UpdateItemLocationOnCheckin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the introduction of this new system preference UpdateItemLocationOnCheckin, the cart to shelf system preference was removed and rolled into this one. However, the alert that comes along with this new system preference is not a welcome addition to the libraries that are using Cart to Shelf functionality. Prior to this, cart to shelf functionality was a backend process that would (without staff interaction) take an item that was checked in, move it to the cart. Now, when an item is checked in (at the system preference UpdateItemLocationOnCheckin has the value _ALL: CART - each time an item is checked in, the staff get a large yellow message box and an alert. If we add a class to this message or even 2 classes this would allow these alert/audio to be turned off for those libraries that don't wish to receive this yellow alert box with every checkin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28895] New: Don't fill in items.location with NewItemsDefaultLocation if blank
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28895 Bug ID: 28895 Summary: Don't fill in items.location with NewItemsDefaultLocation if blank Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On bug 27545 we extended the use of NewItemsDefaultLocation to affect item creation in different place, not only the add item form from the cataloguing module. There is at least one unexpected behaviour (see bug 27545 comment 11): if an item is edited and has a blank location, the syspref's value will be used. We could fix the item edition but it will lead to another inconsistency: if we don't set a location when an item is created, we are enforcing the location to be set to the syspref's value anyway. What's the exact expected behaviour? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 30799] New: Add REST API route to update biblio metadata
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30799 Bug ID: 30799 Summary: Add REST API route to update biblio metadata Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: REST API Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com CC: tomascohen(a)gmail.com Blocks: 17371 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 [Bug 17371] Add routes for biblios [OMNIBUS] -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 33306] New: Agreements list endpoint cannot embed user_roles
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33306 Bug ID: 33306 Summary: Agreements list endpoint cannot embed user_roles Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: agustinmoyano(a)theke.io CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com On bug 32924 the call to GET /api/v1/erm/agreements tries to embed user_roles, but from the API definition it is not allowed -- You are receiving this mail because: You are watching all bug changes.

1 5