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

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #343 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Aleisha Amohia from comment #342) > Thanks for discussing this everyone. If you just decide what the best > behaviour should be and let me know when I need to implement I should be > able to get to this later this week. I think that it would be good for them to be counted as 1 hold for the sake of hold limits. However, I think that's probably easier said than done. Based on my investigations for Bug 15516 and 15565, it seems like the master code for determining hold limits is a mess. One downside of hold groups counting as 1 hold for limits is that it might not be clear to users how many holds they can place as well, although maybe that should be a separate enhancement... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #342 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Thanks for discussing this everyone. If you just decide what the best behaviour should be and let me know when I need to implement I should be able to get to this later this week. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #341 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Brannon from comment #339) > I don't know why this was limited to just the staff client. Maybe it is > with the intent that someone will duplicate it for the OPAC? But if it is > going to be just for staff, I think that it does only have the intended job > from the original request. The original request was not for this to be a > staff only function. Bug 17217 is for the OPAC side, but I think it's incomplete. There are libraries out in the world running a local version of this, but it's different to what's in Bugzilla. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '21

02 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #340 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Christopher Brannon from comment #338) > Is the group hold going to count as one placed hold or count for every item in the group?? At the moment, each member of a group hold counts as its own hold. > If it is > going to show as multiple holds, then it becomes a problem for anyone that > uses it. The group hold HAS to count as a single hold for this to be useful > and not exploited by patrons. I'm not sure what you mean here by "exploited". To me, each member of a group hold counting as a hold is problematic only in terms of hold limits. If you had a limit of 10 holds, and they create 1 hold group with 10 members, then they've exhausted their limit, and that's not necessarily fair to patrons. > Without looking at the code, logically, it seems like if you have each group > hold count as some kind of of proxy hold in the hold system, when Koha looks > to see how many holds there are, it should also see how many group holds > there are, and each group for that user should just reflect as one hold. I > may be over simplifying this. I wouldn't say over simplifying heh. It's quite complex. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '21

01 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28500 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '21

01 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #339 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to David Cook from comment #336) > Also, I notice that the text for the release notes say here that this is > only for the staff interface, so the change for opac/opac-reserve.pl > shouldn't be here at all. > > Since it's only for the staff interface, the concept of a hold group > counting as 1 hold also doesn't make sense, since it would require > complicated hold calculations that would vary depending on the interface. I don't know why this was limited to just the staff client. Maybe it is with the intent that someone will duplicate it for the OPAC? But if it is going to be just for staff, I think that it does only have the intended job from the original request. The original request was not for this to be a staff only function. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '21

01 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #338 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to David Cook from comment #334) > (In reply to Aleisha Amohia from comment #326) > > Ah I remember now - yes, a hold group is supposed to be treated as one hold > > because when one item from that group is confirmed to fill the hold, the > > rest of the group is deleted. > > > > I'll fix this up. > > After reading through the code and further testing and thinking, I don't > think that's feasible. It would require much more refactoring to achieve > that, and I'm not sure that it's worth it. > > So I think if we pull out the count_grouped() code, then this could actually > pass QA, so long as the intention is to create a group of holds, and that > fulfilling one hold will clear the other holds. That works well. > > The counting of the hold group as 1 hold does not work at all though, so > perhaps that concept should be abandoned (for now at least). I'm not sure if I am following correctly or not. Is the group hold going to count as one placed hold or count for every item in the group?? If it is going to show as multiple holds, then it becomes a problem for anyone that uses it. The group hold HAS to count as a single hold for this to be useful and not exploited by patrons. Without looking at the code, logically, it seems like if you have each group hold count as some kind of of proxy hold in the hold system, when Koha looks to see how many holds there are, it should also see how many group holds there are, and each group for that user should just reflect as one hold. I may be over simplifying this. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2486] Show user comments in staff client
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '21

01 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2486 --- Comment #3 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Still valid. Would like to have an easier way to see comments in record. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2486] Show user comments in staff client
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '21

01 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2486 George Williams (NEKLS) <george(a)nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |george(a)nekls.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11999] Add two checks in CanBookBeReserved and CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '21

01 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11999 --- Comment #132 from Arthur Suzuki <arthur.suzuki(a)biblibre.com> --- Hi David, I've not reproduced the issue with t/db_dependent/Holds.t number of tests in Reserves.t has been updated. Kr, -- You are receiving this mail because: You are watching all bug changes.

1 0