(In reply to Martin Renvoize from comment #0)
> In some trusted environments libraries would like their users to self-issue
> without having to use the SCO or SIP checkouts.  i.e. once logged in a user
> should have the ability to check out to themselves much like they already
> have the option to renew and place holds etc.

I've had a number of libraries over the years who would be keen to make use of this.

Work in progress over at https://gitlab.com/mrenvoize/Koha/-/tree/bug_30979.

It's all API driven with a Modal interface for interactions.

So far it will look up an item from it's barcode, check it's availability and give various feedback based on that availability and then attempt to checkout (or require confirm is availability suggests that's required).

The checkout endpoint is still a work in progress.

https://gitlab.com/mrenvoize/Koha/-/tree/bug_30979 even

So, this clearly needs a bit more polishing (and unit tests for the new api routes).. but I'd love to get some feedback.. all the basics are working including a confirmation flow checkouts that require it.

I have installed the patch in a sandbox, I have enabled syspref  OpacTrustedCheckout I. have logged to the opac

I am not able to see at opac-detail, opac-results or in my account the way to seld check out

I have also checked that circ rules are configured
I have also checked that the homebranch of books and users are the same

I had a go at testing what has been done so are - the basic checkout seems to work well.

An example use case could be a small corporate/in house library for an organisation without dedicated/full time library staff that wants to let staff "self-service" so they can checkout and return items without having to use a manual process (such as recording items checked out or in on a register at the door).

Here are my testing notes (using KTD):

Setup
1. Apply patches, updatedatabase, flush_memcached, restart_all
2. Enable OpacTrustedCheckout system preference

Testing the API
1. Get details of items for a record:
   - Visit http://127.0.0.1:8080/api/v1/public/items?external_id=39999000005097
     ==> should return details for the item

Test the self-checkout feature:
1. Go to the OPAC home page
2. Login as a patron (in this case I used koha), and note that in the OPAC header there is now a Self checkout option after Cart and Lists
3. Click on Self checkout ==> window pops up asking you to enter a barcode
4. Enter a barcode for an item that is available, for example: 39999000006094
   ==> Message should say: "Item '39999000006094' was checked out", and an option to enter another barcode, as well as Submit and Close buttons
5. Click close and check your account > your summary: item checked out should be listed
6. Repeat step 4 with the same barcode, this time the result should be:
   ==> Message says: "Item '39999000006094' needs confirmation for the following: RENEW_ISSUE" 
   . Click Confirm (note: currently does nothing, if this is allowed as can renew already from the your summary page)
7. Checkout an item to another patron using the staff interface
   . Example: checked out 39999000011418 to Mary Burton
9. Use the self-checkout to try and checkout this item:
   ==> Message says: "Item '39999000011418' needs confirmation for the following: ISSUED_TO_ANOTHERissued_borrowernumberissued_cardnumberissued_firstnameissued_surname"
   . Click confirm (note: currently does nothing)
10. Use the self-checkout to try and checkout an item on hold:
   . Place a hold for an item using the staff interface. Example: Placed a record level hold for Programming the Perl DBI (biblionumber = 13)
   ==> Message says "Item '39999000000559' needs confirmation for the following: RESERVEDresborrowernumberresbranchcoderescardnumberreserve_idresfirstnameresreservedateressurname" with Confirm and Close buttons
   . Click confirm (note: currently does nothing)
11. Use the self checkout to try and checkout an item on hold for your OPAC patron:
   . Place a record-level hold for an item using the staff interface (used Perl Better Practices, biblionumber = 19)
   . Check in an item for the record and confirm the hold (used 39999000008036), should show status as awaiting pickup
   . Use the self checkout to try and checkout this item to the patron the hold was placed for (39999000008036 and patron koha in this instance)
   ==> Item should be successfully checked out with message "Item '39999000008036' was checked out", with options to enter another barcode, Submit and Close buttons
   ==> Click close and check your account > your summary: item checked out should be listed
12. Try and checkout and item not for loan:
   . Update an item for a record so that is not for loan
   . Try and checkout using the self-checkout
   ==> message says: "Item '39999000005158' cannot be checked out for the following reasons: NOT_FOR_LOANitem_notforloan"
13. Try and checkout an item recorded as Withdrawn:
    . Update an item for a record so that it is withdrawn
   . Try and checkout using the self-checkout
   ==> message says: "Item '39999000005097' cannot be checked out for the following reasons: WTHDRAWN"

Thanks for the comprehensive testing David.

It appears some of the confirmation code got lost during rebases.. I've fixed that now and will upload an updated patchset soon.

You've also highlighted lots of cases where I've not yet fully dealt with error conditions.. I'll work through those now too

Created attachment 141274 [details] [review]
Bug 30979: Add 'OpacTrustedCheckout' preference

This patch adds a new 'OpacTrustedCheckout' system preference to govern
whether the library allows opac users to check out items to themselves
from their OPAC login.

Created attachment 141275 [details] [review]
Bug 30979: Add public items lookup route

This patch adds a /public equivilent to the item listing endpoint.

This allows us to search for an item by it's external_id (barcode).

Test plan
1. Apply patch
2. Perform a GET on /api/v1/public/items?external_id=some_barcode
3. Confirm that the above enpoint correctly returns items that should
   be visible in the OPAC

Created attachment 141276 [details] [review]
Bug 30979: Checkout API's

This patch adds an initial framework for adding/migrating AddIssue from
C4::Circulation into Koha::Checkout... but that feels a bit over scope.

Also.. should we do all the checks and return failure in
Koha::REST::V1::Checkout->add such that we require a new special header
for the equivilent of 'confirm' in the controller script route..

Should we accept an external_id in the checkout add route.. or chain two
ajax requests such that the first looks up the item from it's
external_id and then the second calls checkout upon it?

Should we have a 'CanBookBeIssued' equivilent on the API?

Bug 30979: Add confirmation token to API

This patch adds the creation of a confirmation token to the
get_availability method and then adds a test for the presence of that
same token later in the checkout routine.

Created attachment 141277 [details] [review]
Bug 30979: Add checkout modal to the OPAC

This patch adds a new self checkout modal to the OPAC when
OpacTrustedCheckout is enabled and a user is logged in.

The new modal allows an end user to scan an item barcode, check for item
existance and availability and then check the item out after any
confirmations have been displayed.

Created attachment 141278 [details] [review]
Bug 30979: Fix inconsistent return of AddIssue

AddIssue can on occasion create a renewal instead of a fresh issue and
in such a case we currently return undefined. We should be consistent
and return the existing issue object for the renewal.

Created attachment 141300 [details] [review]
Bug 30979: Handle more failure cases

I tested again using KTD and updated message changes for the test plan. I also added a test for when the patron account has outstanding charges.

Setup
1. Apply patches, updatedatabase, flush_memcached, restart_all
2. Enable OpacTrustedCheckout system preference

Testing the API
1. Get details of items for a record:
   - Visit http://127.0.0.1:8080/api/v1/public/items?external_id=39999000005097
     ==> should return details for the item

Test the self-checkout feature:
1. Go to the OPAC home page
2. Login as a patron (in this case I used koha), and note that in the OPAC header there is now a Self checkout option after Cart and Lists
3. Click on Self checkout ==> window pops up asking you to enter a barcode
4. Enter a barcode for an item that is available, for example: 39999000006094
   ==> Message should say: "Item '39999000006094' was checked out", and an option to enter another barcode, as well as Submit and Close buttons
5. Click close and check your account > your summary: item checked out should be listed
6. Repeat step 4 with the same barcode, this time the result should be:
   ==> Message says: "Item will be renewed" 
   . Click Confirm (note: currently this appears to do nothing - stays on the same screen - it does renew the item though (see your summary))
7. Checkout an item to another patron using the staff interface
   . Example: checked out 39999000011418 to Mary Burton
9. Use the self-checkout to try and checkout this item:
   ==> Message says: 
   "This item appears to be checked out to another patron, please return it to the desk
   Message code 'issued_borrowernumber' with data '49'
   Message code 'issued_cardnumber' with data '23529000651225'
   Message code 'issued_firstname' with data 'Mary'
   Message code 'issued_surname' with data 'Burton'"
   . Click confirm (note that nothing appears to change, however: item is returned, then checked out - no longer checked out to Mary)
10. Use the self-checkout to try and checkout an item on hold:
   . Place a hold for an item for another patron using the staff interface. Example: Placed a record level hold for Programming the Perl DBI (biblionumber = 13)
   ==> Message says:
    "This item appears to be reserved for another patron, please return it to the desk
    Message code 'resborrowernumber' with data '49'
    Message code 'resbranchcode' with data 'MPL'
    Message code 'rescardnumber' with data '23529000651225'
    Message code 'reserve_id' with data '1'
    Message code 'resfirstname' with data 'Mary'
    Message code 'resreservedate' with data '2022-10-05'
    Message code 'ressurname' with data 'Burton'"
   Has Confirm and Close buttons
   . Click confirm (checks item out to you, hold is still in place for the other patron)
11. Use the self checkout to try and checkout an item on hold for your OPAC patron:
   . Place a record-level hold for an item using the staff interface (used Perl Better Practices, biblionumber = 19)
   . Check in an item for the record and confirm the hold (used 39999000008036), should show status as awaiting pickup
   . Use the self checkout to try and checkout this item to the patron the hold was placed for (39999000008036 and patron koha in this instance)
   ==> Item should be successfully checked out with message "Item '39999000008036' was checked out", with options to enter another barcode, Submit and Close buttons
   ==> Click close and check your account > your summary: item checked out should be listed
12. Try and checkout and item not for loan:
   . Update an item for a record so that is not for loan
   . Try and checkout using the self-checkout
   ==> message says: 
      "This item is not normally for loan, please select another or ask at the desk
      Message code 'item_notforloan' with data '1'"
    Has Submit and Close buttons
   ==> Item does not check out, as expected. 
13. Try and checkout an item recorded as Withdrawn:
    . Update an item for a record so that it is withdrawn
   . Try and checkout using the self-checkout
   ==> message says: "This item is marked withdrawn, please select another or ask at the desk"
14. Add a manual charge for the koha patron then try and check out an item.
    . Add a manual invoice for the koha patron of $20.
    ==> message says: "Message code 'DEBT' with data '20'"
    ==> Does not checkout item.

I haven't looked into the code yet but I was wondering how you work out the branch for the checkout.

For a multi-branch library, they might need to self-checkout from multiple different locations. Do we just use the holdingbranch of the item in that case?

Created attachment 145264 [details] [review]
Bug 30979: Add 'OpacTrustedCheckout' preference

This patch adds a new 'OpacTrustedCheckout' system preference to govern
whether the library allows opac users to check out items to themselves
from their OPAC login.

Created attachment 145265 [details] [review]
Bug 30979: Add public items lookup route

This patch adds a /public equivilent to the item listing endpoint.

This allows us to search for an item by it's external_id (barcode).

Test plan
1. Apply patch
2. Perform a GET on /api/v1/public/items?external_id=some_barcode
3. Confirm that the above enpoint correctly returns items that should
   be visible in the OPAC

Created attachment 145266 [details] [review]
Bug 30979: Public checkout API's

This patch adds API's to allow for a checkout flow using the RESTful
API.

We add an availability endpoint to check an items current availability
status. The endpoint can be found at `/public/checkouts/availability`
and is a GET request that requires item_id and patron_id passed as
parameters.  We return an availability object that includes blockers,
confirms, warnings and a confirmation token to be used for checkout.

We also add a corresponding checkout endpoint at `/public/checkouts`
that accepts a POST request with checkout details including item_id and
a confirmation token in the body.

Future work: We should properly migrate CanBookBeIssued into Koha::* and
use that here instead of refering to C4::Circulation.

Created attachment 145267 [details] [review]
Bug 30979: Fix inconsistent return of AddIssue

AddIssue can on occasion create a renewal instead of a fresh issue and
in such a case we currently return undefined. We should be consistent
and return the existing issue object for the renewal.

Created attachment 145268 [details] [review]
Bug 30979: Add checkout modal to the OPAC

This patch adds a new self checkout modal to the OPAC when
OpacTrustedCheckout is enabled and a user is logged in.

The new modal allows an end user to scan an item barcode to checkout.
We check for item existance and availability and then check the item
out after any confirmations have been displayed.

(In reply to David Cook from comment #20)
> I haven't looked into the code yet but I was wondering how you work out the
> branch for the checkout.
> 
> For a multi-branch library, they might need to self-checkout from multiple
> different locations. Do we just use the holdingbranch of the item in that
> case?

I don't touch the existing code for that at all.. we're calling 'AddIssue' within the API here and that uses the logic in '_GetCircControlBranch'.. which I believe looks at environment.

Rebased and tidied up a bit.. but I still need to take care of some of the reserves and checked out to another user related issues.. I feel we're leaking some details we shouldn't be on the public API at the current state.

Created attachment 145277 [details] [review]
Bug 30979: Remove data from publically facing API

The availability API was leaking some patron information for certain
cases.

This bug adds a deny-list to remove the leaked fields.

Created attachment 145280 [details] [review]
Bug 30979: Add 'OpacTrustedCheckout' preference

This patch adds a new 'OpacTrustedCheckout' system preference to govern
whether the library allows opac users to check out items to themselves
from their OPAC login.

Created attachment 145281 [details] [review]
Bug 30979: Add public items lookup route

This patch adds a /public equivilent to the item listing endpoint.

This allows us to search for an item by it's external_id (barcode).

Test plan
1. Apply patch
2. Perform a GET on /api/v1/public/items?external_id=some_barcode
3. Confirm that the above enpoint correctly returns items that should
   be visible in the OPAC

Created attachment 145282 [details] [review]
Bug 30979: Public checkout API's

This patch adds API's to allow for a checkout flow using the RESTful
API.

We add an availability endpoint to check an items current availability
status. The endpoint can be found at `/public/checkouts/availability`
and is a GET request that requires item_id and patron_id passed as
parameters.  We return an availability object that includes blockers,
confirms, warnings and a confirmation token to be used for checkout.

We also add a corresponding checkout endpoint at `/public/checkouts`
that accepts a POST request with checkout details including item_id and
a confirmation token in the body.

Future work: We should properly migrate CanBookBeIssued into Koha::* and
use that here instead of refering to C4::Circulation.

Created attachment 145283 [details] [review]
Bug 30979: Remove data from publically facing API

The availability API was leaking some patron information for certain
cases.

This bug adds a deny-list to remove the leaked fields.

Created attachment 145284 [details] [review]
Bug 30979: Fix inconsistent return of AddIssue

AddIssue can on occasion create a renewal instead of a fresh issue and
in such a case we currently return undefined. We should be consistent
and return the existing issue object for the renewal.

Created attachment 145285 [details] [review]
Bug 30979: Add checkout modal to the OPAC

This patch adds a new self checkout modal to the OPAC when
OpacTrustedCheckout is enabled and a user is logged in.

The new modal allows an end user to scan an item barcode to checkout.
We check for item existance and availability and then check the item
out after any confirmations have been displayed.

Lots of little refinements went in this time.. I reckon we're back to NSO. :)

Updated test plan I used (using KTD).

Setup
1. Apply patches, updatedatabase, flush_memcached, restart_all
2. Enable OpacTrustedCheckout system preference

Testing the API
1. Get details of items for a record:
   - Visit http://127.0.0.1:8080/api/v1/public/items?external_id=39999000005097
     ==> should return details for the item

Test the self-checkout feature:
1. Go to the OPAC home page.
2. Login as a patron (in this case I used koha), and note that in the OPAC header there is now a Self checkout option after Cart and Lists.
3. Click on Self checkout ==> window pops up asking you to enter a barcode.
4. Enter a barcode for an item that is available, for example: 39999000006094
   ==> Message should say: "Item '39999000006094' was checked out", and an option to enter another barcode, as well as Submit and Close buttons.
5. Click close and check your account > your summary: item checked out should be listed.
6. Repeat step 4 with the same barcode, this time the result should be:
   ==> Message says: "Item will be renewed" 
   . Click Confirm
   ==> Message says "Item '39999000006094' was checked out". There is also an input box to enter another item barcode, and there may also be a list of barcodes checked out and the due date.
7. Checkout an item to another patron using the staff interface.
   . Example: checked out 39999000011418 to Mary Burton
9. As the patron in step 2, use the self-checkout to try and checkout this item:
   ==> Message says: "This item appears to be checked out to another patron, please return it to the desk"
   . Has Submit and Close buttons
   . Click the Close button
10. Use the self-checkout to try and checkout an item on hold:
   . Place a hold for an item for another patron using the staff interface. Example: Placed a record level hold for Programming the Perl DBI (biblionumber = 13)
   ==> Message says: "This item appears to be reserved for another patron, please return it to the desk"
   . Has Submit and Close buttons
   . Click the Close button
11. Use the self checkout to try and checkout an item on hold that is waiting for pickup for a patron (I used koha):
   . Place a record-level hold for an item using the staff interface (used Perl Better Practices, biblionumber = 19)
   . Check in an item for the record and confirm the hold (used 39999000008036), should show status as awaiting pickup
   . Use the self checkout to try and checkout this item to the patron the hold was placed for (39999000008036 and patron koha in this instance)
   ==> Item should be successfully checked out with message "Item '39999000008036' was checked out", with options to enter another barcode, Submit and Close buttons
   ==> Click close and check your account > your summary: item checked out should be listed
12. Repeat step 11, but use the self checkout to try and checkout an item that is on hold and waiting for pickup by another patron (I used Mary Burton to place the hold, and koha to check it out):
    ==> Message says: "Message code 'RESERVE_WAITING' with data '1' Message code 'reswaitingdate' with data '2023-01-13'"
    . Has Confirm and Close buttons
    . Confirm button: 
      - checks out item to patron who didn't have the hold waiting (koha)
      - item shows (in the staff interface) as checked out to koha, and also waiting for pickup (for Mary)
13. Try and checkout and item not for loan:
    . Update an item for a record so that is not for loan
    . Try and checkout using the self-checkout
    ==> message says: "This item is not normally for loan, please select another or ask at the desk"
    . Has Submit and Close buttons
    ==> Item does not check out, as expected. 
14. Try and checkout an item recorded as Withdrawn:
    . Update an item for a record so that it is withdrawn
    . Try and checkout using the self-checkout
    ==> message says: "This item is marked withdrawn, please select another or ask at the desk"
15. Add a manual charge for the koha patron then try and check out an item.
    . Add a manual invoice for the koha patron of $20.
    ==> message says: "Your account is currently in debt by '20'"
    ==> Does not checkout item.

Hi Martin.

The only wrinkles I found this time were:

1. Step 12 - checkout an item that is waiting for pickup by another patron: was able to checkout the item waiting, even though it wasn't for me.

 ==> Message says: "Message code 'RESERVE_WAITING' with data '1' Message code 'reswaitingdate' with data '2023-01-13'"
    . Has Confirm and Close buttons
    . Confirm button: 
      - checks out item to patron who didn't have the hold waiting (koha)
      - item shows (in the staff interface) as checked out to koha, and also waiting for pickup (for Mary)

2. Barcodes with a space before it - items aren't found: I recall testing another bug for this, but can't find it. But anyway, this is not specifically related to this bug.

I didn't try and use the public API to query for items that are hidden/not visible in the OPAC (not entirely sure how to set this up properly).

Created attachment 145620 [details] [review]
Bug 31699: Add 'return' option to opac modal login

This patch adds the option to trigger a redirect back to the current
context after successful login using modal logins triggered from various
places in the OPAC.

To make use of this, simply add 'data-return="true"' to the modal trigger link.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>

Created attachment 145621 [details] [review]
Bug 31699: (follow-up) Protect against unauthorized redirects

Created attachment 145622 [details] [review]
Bug 31699: (follow-up) Protect more against open redirects

This change checks that the OPACBaseURL exists, and uses its scheme
and authority to rewrite the URL passed through the "return"
param.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Created attachment 145623 [details] [review]
Bug 30979: Add 'OpacTrustedCheckout' preference

This patch adds a new 'OpacTrustedCheckout' system preference to govern
whether the library allows opac users to check out items to themselves
from their OPAC login.

Created attachment 145624 [details] [review]
Bug 30979: Add public items lookup route

This patch adds a /public equivilent to the item listing endpoint.

This allows us to search for an item by it's external_id (barcode).

Test plan
1. Apply patch
2. Perform a GET on /api/v1/public/items?external_id=some_barcode
3. Confirm that the above enpoint correctly returns items that should
   be visible in the OPAC

Created attachment 145625 [details] [review]
Bug 30979: Public checkout API's

This patch adds API's to allow for a checkout flow using the RESTful
API.

We add an availability endpoint to check an items current availability
status. The endpoint can be found at `/public/checkouts/availability`
and is a GET request that requires item_id and patron_id passed as
parameters.  We return an availability object that includes blockers,
confirms, warnings and a confirmation token to be used for checkout.

We also add a corresponding checkout endpoint at `/public/checkouts`
that accepts a POST request with checkout details including item_id and
a confirmation token in the body.

Future work: We should properly migrate CanBookBeIssued into Koha::* and
use that here instead of refering to C4::Circulation.

Created attachment 145626 [details] [review]
Bug 30979: Remove data from publically facing API

The availability API was leaking some patron information for certain
cases.

This bug adds a deny-list to remove the leaked fields.

Created attachment 145627 [details] [review]
Bug 30979: Fix inconsistent return of AddIssue

AddIssue can on occasion create a renewal instead of a fresh issue and
in such a case we currently return undefined. We should be consistent
and return the existing issue object for the renewal.

Created attachment 145628 [details] [review]
Bug 30979: Add checkout modal to the OPAC

This patch adds a new self checkout modal to the OPAC when
OpacTrustedCheckout is enabled and a user is logged in.

The new modal allows an end user to scan an item barcode to checkout.
We check for item existance and availability and then check the item
out after any confirmations have been displayed.

Created attachment 145629 [details] [review]
Bug 30979: Always show self-checkout when preference enabled

This patch updates the display logic such that if the truested
self-checkout option is enabled we always show the checkout button and
prompt a login when no user is found.

Created attachment 145630 [details] [review]
Bug 30979: Redirect to checkout summary

This is a temporary solution whilst we wait for the biblio api endpoints
so we may include more biblio details in the checkout modal itself.

I've run the test plan in comment #36 again.

The issue for step 12 mention in comment #37 still applied. Would be happy for this to be treated as a separate bug if required, as it is possibly an edge case.

Also, if no user is logged in, I don't get a login prompt when I click on 'Self checkout'.

We had a discussion about a trusted self checkout feature this week and the question about checking out items already checked out to another came up. The request was, that it should be possible to do this in a trusted environment. I can imagine it makes sense and it avoids people taking the item anyway, writing a note etc. Maybe it could be handled differently here than in the normal SCO as we assume a higher level of trust or could be made configurable.

Katrin, could you explain a bit more about what you mean by "trusted environment", please?

(In reply to Martin Renvoize from comment #0)
> In some trusted environments libraries would like their users to self-issue
> without having to use the SCO or SIP checkouts.  i.e. once logged in a user
> should have the ability to check out to themselves much like they already
> have the option to renew and place holds etc.

Mostly citing Martin :)

With this feature you do have to trust the people checking out and checking in, because they could practically do anything, they are probably alone in the rooms of the library. It will work from every computer, from a mobile phone etc. you won't be able to watch them. It will also work from their home computers, they could just check in whatever they had checked out before.

--> So if they can access an item that is checked out to someone else, we should maybe only warn, but assume that it's better to track than to forbid.

Perhaps we should have options to handle different cases.  For each case we have an option to check out or ask that the item be brought to a staff member for further action.  Maybe also an option to run this feature from a specific IP.  I could see this getting abused if a patron runs out of renewals, and (Is self check in a feature?  Not sure that it needs to be, but should be able to independently turn that off.) if they can check it in, the check it in and then check it out.  If the library gives rights to check out if it is in hand (like sco and staff might allow) then they could have something indefinitely.  There definitely needs to be some safeguards if self check in is a thing.

So, we now have a backported version of this (at 21.11) at one site and it's likely to hit landfall at a few more imminently.

I need to write unit tests and get community folks opinions on the API design.

Right now it's designed to mimick the behaviour of the normal SCO in terms of blocks and checks and. I think opening it up further should be proposed in their own follow-up bugs so we can get the core feature in sooner.

Really great to see people interested in this.

*** Bug 30444 has been marked as a duplicate of this bug. ***

I've reviewed Martin's rebase and it's looking good! I've reset the status to assigned so Martin can change it back to NSO when the patch set is ready!

Hmm.. the rebase on 23336 broke something here.. working on a fresh rebase

Just another rebase to make sure it still applies clean.

Pushed to master for 23.11.

Nice work everyone, thanks!

Created attachment 153500 [details] [review]
Bug 30979: (QA follow-up) Add missing docs on error codes

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Created attachment 153501 [details] [review]
Bug 30979: (QA follow-up) Tidy things

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Created attachment 153502 [details] [review]
Bug 30979: Fix regression

This patch fixes a regression introduced by the 'Fix public availability
500' follow-up.

To test:
1. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/checkouts.t
=> FAIL: Tests fail!
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass! Tests are useful!
4. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Created attachment 153503 [details] [review]
Bug 30979: Fix xt/api.t

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

New feature, no backport for 23.05.x series.