[Koha-bugs] [Bug 21346] Clean up dialogs in returns.pl / Fix waiting holds at wrong location bug

2018-11-03 Thread bugzilla-daemon
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21346

Christopher Brannon  changed:

   What|Removed |Added

  Attachment #81921|0   |1
is obsolete||

--- Comment #34 from Christopher Brannon  ---
Created attachment 81924
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=81924=edit
Bug 21346: Convert dialogs to modals.

This addresses most of the transfer dialogs.  There are some dialogs
that I have not converted because I don't know what triggers them,
therefore I cannot test them.

The following scenarios have been addresses, and should be tested:

FOR TRANSFERS

1) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn
set to Don't)
 * Should give 3 options - Yes, Yes with print, or No.
 * Yes and Yes with print should trigger a transfer back home.
 * No should do nothing.
 * Print should open a window for printing, with correct
 information.
 * All three options should close the modal.

 TO TEST:
 1) Set AutomaticItemREturn to Don't.
 2) Check in an item with no issues, holds or transfers set, at a
 location other than the owning library.
 3) Test conditions above.

2) Checkin with no issue, hold or transfer; not at home (AutomaticItemReturn
set to Do)
* Should give 2 options - Print or OK.
* Should automatically set transfer.
* Print should open a window for printing, with correct information.
* Both buttons should close modal.

TO TEST:
1) Set AutomaticItemReturn to Do.
2) Check in an item with no issues, holds or transfers set, at a
location other than the owning library.
3) Test conditions above.

3) Checkin with no issues or holds, but transfer already set
* Should give 3 options - OK, Print or Cancel.
* OK and print should not touch existing transfer.
* Cancel should remove the exisiting transfer.
* Print should open a window for printing, with correct information.
* All three options should close the modal.

TO TEST:
1) Check in an item following step 2 of either test above.
2) Check in item again, while a transfer exists.
3) Test conditions above.

WRONG BRANCH

4) If AllowReturnToBranch is not set "to any library", and the item is not
checked in at the appropriate branch, the wrong-branch-modal pops up:
* Should give 1 option - OK.
* Should not check anything in or initiate a transfer.
* OK should close the modal.

TO TEST:
1) Set AllowReturnToBranch to "only the library the item is from".
You can test the other settings, as long as you pay attention to
where you are checking the item in at.
2) Check in an item at a branch other than the owning library.
3) Test conditions above.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


[Koha-bugs] [Bug 20582] Turn Koha into a Mojolicious application

2018-11-03 Thread bugzilla-daemon
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582

--- Comment #28 from Jerome Charaoui  ---
(In reply to Julian Maurice from comment #27)
> (In reply to Jerome Charaoui from comment #26)
> > Thank you for being so quick to provide a patch!
> > 
> > I can confirm that it fixes upload functions within Koha.
> 
> Thank you for testing it ;)
> 
> (In reply to Jerome Charaoui from comment #25)
> > Created attachment 81857 [details] [review] [review]
> > Fix PDF generation
> > 
> > Here's a patch to fix generating PDFs from the Acquisitions module.
> 
> How did you generate this patch ? It's modifying a path that doesn't exist
> (b/site/profile/files/koha/lib/Koha/App/Koha.pm), I bet it won't apply
> nicely with `git bz apply`.
> Also the fix in itself references a path that only exist on 'standard'
> install (intranet/cgi-bin/acqui) so it won't work on a 'dev' install. Can
> you provide steps to reproduce the bug ?

Oops, sorry for fumbling that patch, my bad.

The following error message is generated when exporting a acquisitions
basketgroup in PDF format (https://imgur.com/a/UmXpppW) :

[debug] GET "/cgi-bin/koha/acqui/basketgroup.pl"
[debug] Routing to a callback
[error] Undefined subroutine
::Compile::ROOT::usr_share_koha_intranet_cgi_2dbin_acqui_basketgroup_2epl::printpdf
called at /usr/share/koha/intranet/cgi-bin/acqui/basketgroup.pl line 213.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


[Koha-bugs] [Bug 21701] Have PayPal optionally return to originating OPAC url rather than OPACBaseURL

2018-11-03 Thread bugzilla-daemon
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21701

David Kuhn  changed:

   What|Removed |Added

Summary|Have PayPal return to   |Have PayPal optionally
   |originating OPAC url rather |return to originating OPAC
   |than OPACBaseURL|url rather than OPACBaseURL

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


[Koha-bugs] [Bug 20210] Claimed Return

2018-11-03 Thread bugzilla-daemon
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20210

Brian  changed:

   What|Removed |Added

 CC||bkl...@dubuque.lib.ia.us

--- Comment #1 from Brian  ---
Any updates on bug 20210?

Carnegie Stout Staff would be grateful

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


[Koha-bugs] [Bug 20582] Turn Koha into a Mojolicious application

2018-11-03 Thread bugzilla-daemon
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582

--- Comment #27 from Julian Maurice  ---
(In reply to Jerome Charaoui from comment #26)
> Thank you for being so quick to provide a patch!
> 
> I can confirm that it fixes upload functions within Koha.

Thank you for testing it ;)

(In reply to Jerome Charaoui from comment #25)
> Created attachment 81857 [details] [review]
> Fix PDF generation
> 
> Here's a patch to fix generating PDFs from the Acquisitions module.

How did you generate this patch ? It's modifying a path that doesn't exist
(b/site/profile/files/koha/lib/Koha/App/Koha.pm), I bet it won't apply nicely
with `git bz apply`.
Also the fix in itself references a path that only exist on 'standard' install
(intranet/cgi-bin/acqui) so it won't work on a 'dev' install. Can you provide
steps to reproduce the bug ?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/


[Koha-bugs] [Bug 21753] issuingrules.chargename is unused and should be removed

2018-11-03 Thread bugzilla-daemon
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21753

--- Comment #4 from Martin Renvoize  ---
Test Plan

Pre-patch:
1) Verify that there is no way to populate this field (short of manually
entering data at the command line using SQL)
  - As far as I can tell, the issuingrules table is always set via the
circulation map and there is not option to 'name' each circ rule.

Post-patch:
1) Verify that fines are still calculated correctly
2) Verify that all the circulation related tests still pass (or run the entire
test suit to be especially sure there are no unseen wider implications)

Notes:
The field, should it ever have been available for input, would have displayed
as part of the fines message in the action logs (if finelogs was turned on) and
as part of the textual output if you ran the fines cronjob in verbose mode. 
However, as it was never filled it obviously wasn't ever output.

Hope that helps.. it's hard to come up with a test plan for something that
removes a field that was never visible to the end user (or used functionally
internally either).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/