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

[Bug 13099] New: "Item hasn't been transferred yet" shows pickup branch rather than holding branch
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13099 Bug ID: 13099 Summary: "Item hasn't been transferred yet" shows pickup branch rather than holding branch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 The "Item hasn't been transferred yet" message on circulation.pl and moremember.pl in the holds table shows the pickup branch rather than holding branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 13288] New: Saved reports tabs broken by DataTables upgrade
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13288 Bug ID: 13288 Summary: Saved reports tabs broken by DataTables upgrade Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 12986 Bug 12986 (Upgrade the DataTables jQuery plugin to the latest version (1.10.2)) broke the saved reports tabs for "groups" like Accounts, Acquistitions, Catalog, etc. Clicking any tab other than "All" shows no reports. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 1861] Unique patrons logins not (totally) enforced
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1861 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33751|0 |1 is obsolete| | --- Comment #18 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 33752 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33752&action=edit Bug 1861 [QA Followup] - Don't modify userids, warn if we can't modify the index automatically -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1861] Unique patrons logins not (totally) enforced
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1861 --- Comment #17 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 33751 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33751&action=edit Bug 1861 [QA Followup] - Don't modify userids, warn if we can't modify the index automatically -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1861] Unique patrons logins not (totally) enforced
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1861 --- Comment #16 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 33750 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33750&action=edit Bug 1861 [QA Followup] - Fix Check_Userid and unit tests Check_Userid assumes that a borrowernumber will always be passed in and thus fails to to return 0 for an already used userid when creating a new patron. Unit tests must now also me modified to no longer assume it is possible to create multiple patrons with the same userid. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1861] Unique patrons logins not (totally) enforced
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1861 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #33143|0 |1 is obsolete| | Attachment #33144|0 |1 is obsolete| | --- Comment #15 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 33749 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33749&action=edit Bug 1861 - Unique patrons logins not (totally) enforced The Koha 3.0 patron admin page will prevent you from creating a user who has an identical OPAC login as someone else (though I would change the error message from "Login/password already exists." to "Login already exists.", since it's not the password that's the problem). However, there's nothing enforced in the MySQL database to prevent patrons from being imported or manually inserted with duplicate logins. Would it be better to change the MySQL spec from this: KEY `userid` (`userid`) to this: UNIQUE KEY `userid` (`userid`) Test plan: 1) Enter mysql console 2) Attempt to create two borrowers with identical user id's 3) Note you are able to do so 4) Delete these bororwers 5) Apply this patch 6) Run updatedatabase.pl 7) Repeat step 2 8) Note you are now unable to do so Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel(a)gmail.com> Work as described, no koha-qa errors Signed-off-by: Katrin Fischer <Katrin.Fischer.83(a)web.de> Leaves deletedborrowers as it is, deleting patrons still works ok. Works according to test plan. Database update will only be successful, when no duplicate entries exist in the database. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1861] Unique patrons logins not (totally) enforced
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1861 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13313] New: RecordLocalUseOnReturn
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13313 Bug ID: 13313 Summary: RecordLocalUseOnReturn Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com For discussion: Should RecordLocalUseOnReturn be recording local use based off whether or not the item is checked out, as it does now, or should it record local use when it isn't doing anything else? For example, I notice it records local use if I trigger an item for transfer or holds, if the item wasn't checked out. If I scan again (maybe to refresh a hold or print a slip, it records local use. Is this desired behavior? Should we make it an option? Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13311] New: NewItemsDefaultLocation preference should not populate items.permanent_location
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13311 Bug ID: 13311 Summary: NewItemsDefaultLocation preference should not populate items.permanent_location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I noticed this problem when testing Bug 13297: If you have NewItemsDefaultLocation turned on (set to use the "PROC" authorized value for instance), and you add a new item to a record through the cataloging interface but you *don't* select a shelving location, both items.location and items.permanent_location will be filled with "PROC." This is incorrect. Only items.location should be filled. If items.permanent_location is also "PROC," then checking in the item will not trigger removal of the "PROC" value as it should. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11427] New: Allow NewItemsDefaultLocation to be set per branch
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11427 Bug ID: 11427 Summary: Allow NewItemsDefaultLocation to be set per branch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: p.thrasher(a)dover.nh.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Different branches have different initial default locations for new items. NewItemsDefaultLocation is a systemwide preference. Can it be changed to be a branch specific preference? -- You are receiving this mail because: You are watching all bug changes.

1 1