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

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3387 --- Comment #10 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Good catch, it's just one of those days... : )= > One new problem, however, with the follow-up: the "<strong>NOT CHECKED > IN</strong>" message is being displayed whether or not the item was checked > in (i.e. for either setting of BlockReturnOfWithdrawnItems) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3387 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #10907|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3387 --- Comment #9 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 10911 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10911&action=edit Bug 3387 - WITHDRAWN items shouldn't check in - Followup -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3387 --- Comment #8 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to comment #4) > This is an existing bug and is outside the scope of this patch. I will file > a separate bug report for it. The problem is mitigated greatly by the improved warning message. > > 3. If I have the preference set to "Don't block" I think I should see a > > "dialog message" style message that the item is marked as withdrawn so that > > the staff has the option of taking action. > > A message is already displayed. I guess I assumed a message wasn't displayed at all because it's not displaying under this condition: When checking in a withdrawn item which must be transferred to another branch. And in that case I suppose the alert about the status can be deferred until it's at its destination. One new problem, however, with the follow-up: the "<strong>NOT CHECKED IN</strong>" message is being displayed whether or not the item was checked in (i.e. for either setting of BlockReturnOfWithdrawnItems) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3387 --- Comment #7 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to comment #6) > I just tested the assertion that "Koha does not allow for returning of items > marked as Withdrawn" on master. > > This is untrue - you can check in a book that has been withdrawn, and > furthermore, it will attempt to continue to fill holds even though it is > withdrawn and "cannot be checked out." Either you are mistaken, or some part of your configuration is allowing withdrawn items to be returned. I'm using only the example data that comes with Koha. Here is a screencast showing this behavior in action: http://screencast.com/t/6OYjRlju > Does this patch address the original bug, which was "block check out of > books that are withdrawn?" The original bug was "block check *in* of books that are withdrawn" and I stated that my testing has shown that this is how Koha is currently working. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3701] If the ReturnToShelvingCart syspref is on, and something needs to go in transit, the shelving cart setting is overriding the transit.
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3701 --- Comment #13 from Kyle M Hall <kyle(a)bywatersolutions.com> --- I think you are absolutely right. I have just submitted a modified version of the patch that moves this logic in AddReturn(), rather than leaving it in returns.pl I'm leaving the status as Passed QA for now. If you feel this new version needs to restart the submission process, please go ahead and reset the status to "Needs Signoff". (In reply to comment #11) > mmm... I don't like this patch, but still not sure it's wrong. > > Here is why I don't like it: > > You write: > + if ( C4::Context->preference("ReturnToShelvingCart") && > !$messages->{'WasTransfered'} ) { > + my $item = GetItem( $itemnumber ); > + $item->{'location'} = 'CART'; > + ModItem( $item, $item->{'biblionumber'}, $item->{'itemnumber'} ); > + } > > in return.pl > > So, you manage the ShelvingCart: > * outside from AddReturn sub => what would happen if I mark return from > circulation.pl (I can to that by checking the checkbox on the right of any > issued item, and "renew or return checked items") ? Same thing for > moremember.pl. Overall, I feel it's unsafe to manage that outside AddReturn > > * you use $messages->{'WasTransfered'} to check if there has been a > transfer. That's a little bit unsafe. If we remove the message, or change > the use of the message, we may face side-effect > > I don't failed QA this patch for now, please argue if you think i'm wrong. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3701] If the ReturnToShelvingCart syspref is on, and something needs to go in transit, the shelving cart setting is overriding the transit.
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3701 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #10874|0 |1 is obsolete| | --- Comment #12 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 10908 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10908&action=edit BugFix - ReturnToShelvingCart If the ReturnToShelvingCart syspref is on, and something needs to go in transit, the shelving cart setting is overriding the transit. What seems to be happening is this: * Item is checked in, and flagged as needing to go in transit from A to B. * Item is immediately flagged as shelving cart, though. Current display says both shelving cart and in transit. * After the cart-to-shelf script runs, item comes out of transit and shows as being available at the destination library, although it hasn't arrived yet and no one has manually checked it in. http://bugs.koha-community.org/show_bug.cgi?id=3701 Signed-off-by: Jonathan Druart <jonathan.druart(a)biblibre.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3387 Liz Rea <wizzyrea(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wizzyrea(a)gmail.com --- Comment #6 from Liz Rea <wizzyrea(a)gmail.com> --- I just tested the assertion that "Koha does not allow for returning of items marked as Withdrawn" on master. This is untrue - you can check in a book that has been withdrawn, and furthermore, it will attempt to continue to fill holds even though it is withdrawn and "cannot be checked out." Does this patch address the original bug, which was "block check out of books that are withdrawn?" -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3387] WITHDRAWN items shouldn't check in
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

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

1 0

[Bug 7729] New: svc API should allow creation and deletion of items
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '12

17 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7729 Priority: P5 - low Change sponsored?: Sponsored Bug ID: 7729 Assignee: mjr(a)ttllp.co.uk Summary: svc API should allow creation and deletion of items QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: mjr(a)ttllp.co.uk URL: http://koha:8080/svc/biblio Hardware: All Status: ASSIGNED Version: unspecified Component: Architecture, internals, and plumbing Product: Koha The svc new_biblio and biblio scripts delete items, but it's not clear why. Item creation over svc is a desirable option. The svc API should also support deletion of items - maybe using HTTP DELETE method. -- You are receiving this mail because: You are watching all bug changes.

1 22