There is certainly a need for this to be able to add charges to the patron accounts from other library services/web applications. An example would be a print management software where the user is charged for the number of printouts.
For further information see attached documentation. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee
Created attachment 144615 [details] Add routes to add debits
I could have swarn I'd already submitted code for this.. I'll see if I can dig out the relevant branch and get it rebased and submitted.
See bug 29453
The above reworks a bunch of the foundations to make adding this much easier.
Created attachment 144623 [details] [review] Bug 21043: Untested code This patch adds a rough idea of how we might go about adding such an api point.
I don't really have the capacity to work on this right now.. but I've added a basic patch for how I could see it fitting together.. untested.
Created attachment 147457 [details] [review] Bug 21043: Add debit REST endpoint This patch adds an endpoint to create a debit for a patron. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee
Created attachment 147458 [details] [review] Bug 21043: (follow-up) fix minor bugs and add test case
Created attachment 147459 [details] [review] Bug 21043: Add debit REST endpoint This patch adds an endpoint to create a debit for a patron. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee Sponsored-by: The Research University in the Helmholtz Association (KIT)
Created attachment 147498 [details] [review] Bug 21043: Add debit REST endpoint This patch adds an endpoint to create a debit for a patron. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee Sponsored-by: The Research University in the Helmholtz Association (KIT) Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Created attachment 147566 [details] [review] Bug 21043: Add debit REST endpoint This patch adds an endpoint to create a debit for a patron. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee Sponsored-by: The Research University in the Helmholtz Association (KIT) Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Created attachment 147567 [details] [review] Bug 21043: (follow-up) Handle exceptions and switch to debit response We were cheating a bit here and expecting a 'debit' to be sent in but a 'line' to be returned. We should really be sending a debit and returning a debit.. so I've update the paths schema as such.. but a little more work needs doing to get it all working. I've also added some code to catch exceptions that can be thrown by Koha::Account->add_debit and added the appropriate 400 errors into the path specs again.
Created attachment 147568 [details] [review] Bug 21043: (follow-up) Return Koha::Account::Debit This patch updates Koha::Account->add_debit from returning a Koha::Account::Line object to returning a Koha::Account::Debit object. This shouldn't make any difference for internal code at the moment, as we're using Koha::Account::Line as the base class for ::Credit and ::Debit classes.. but we do overload the to_api_mapping and this is causing some tests to fail. We still need a little work here.
So in review I spotted a few things that need taking care of and started following up. There's still a little more to do, but I've run out of tuits for today. I think a good chunk of work needs doing on the blocker bug to progress this so I'm going to focus there to get it unblocked.
Created attachment 147642 [details] [review] Bug 21043: Add debit REST endpoint This patch adds an endpoint to create a debit for a patron. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee Sponsored-by: The Research University in the Helmholtz Association (KIT) Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 147643 [details] [review] Bug 21043: Handle exceptions and switch to debit response We were cheating a bit here and expecting a 'debit' to be sent in but a 'line' to be returned. We should really be sending a debit and returning a debit.. so I've update the paths schema as such and we're now coercing the Koha::Account::Line object that's returned by Koha::Account->add_debit into a Koha::Account::Debit object. Longer term it would be nice to convert returns from the various Koha::Account methods to their correct Koha::Account:: objects as apposed to them all being the base ::Line I've also added some code to catch exceptions that can be thrown by Koha::Account->add_debit and added the appropriate 400 errors into the path specs again. Finally.. I added more unit tests to prove the above Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Could you review my follow-up Agustin?
(In reply to Martin Renvoize from comment #19) > Could you review my follow-up Agustin? Changing status to reflect need for feedback.
The follow-up is correct.
Created attachment 150765 [details] [review] Bug 21043: Add debit REST endpoint This patch adds an endpoint to create a debit for a patron. Testplan 1. Create a new account debit type (Administration > Debit types) 2. Add a fee with this debit type to a patron’s account via API 3. Make sure that this fee is shown in the accounting overview in the patron’s account in the staff interface 4. Make sure that it is possible to make a payment for this fee Sponsored-by: The Research University in the Helmholtz Association (KIT) Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150766 [details] [review] Bug 21043: Handle exceptions and switch to debit response We were cheating a bit here and expecting a 'debit' to be sent in but a 'line' to be returned. We should really be sending a debit and returning a debit.. so I've update the paths schema as such and we're now coercing the Koha::Account::Line object that's returned by Koha::Account->add_debit into a Koha::Account::Debit object. Longer term it would be nice to convert returns from the various Koha::Account methods to their correct Koha::Account:: objects as apposed to them all being the base ::Line I've also added some code to catch exceptions that can be thrown by Koha::Account->add_debit and added the appropriate 400 errors into the path specs again. Finally.. I added more unit tests to prove the above Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Pushed to master for 23.05. Nice work everyone, thanks!
New feature, not backporting to 22.11.x series (again.. for API's I'm always tempted, so let me know if you're keen for this to make the cut)