Can we use mod-patron to renew items?

[marlo-longley]

In #renew_item_request we're using the /circulation/renew-by-id', json: { itemId: item_id, userId: user_id } end point and posting some JSON. I wonder if there's a reason we'd prefer to use the patron API at /patron/account/{id}/item/{itemId}/renew? Would need to test.

[marlo-longley]

Here are the differences as I read them:
mod-circulation - operates on the Loan object, which contains a lot of data. Example response from docs is the entire Loan object with associated service points, policies, etc.:

{
  "id": "cf23adf0-61ba-4887-bf82-956c4aae2260",
  "userId": "df7f4993-8c14-4a0f-ab63-93975ab01c76",
  "proxyUserId": "346ad017-dac1-417d-9ed8-0ac7eeb886aa",
  "itemId": "cb20f34f-b773-462f-a091-b233cc96b9e6",
  "item": {
    "title": "The Long Way to a Small, Angry Planet",
    "barcode": "036000291452",
    "status": {
      "name": "Checked out"
    },
    "location": {
      "name": "Main Library"
    },
    "materialType": {
      "name": "Book"
    },
    "contributors": [
      {
        "name": "Steve Jones"
      }
    ]
  },
  "loanPolicyId" : "e9af4ba4-6801-4722-be45-d7a49d13564d",
  "loanPolicy": {
    "name" : "Can Circulate Rolling"
  },
  "overdueFinePolicyId": "b59fe39f-efdc-4a88-993a-04fb405e5ecc",
  "overdueFinePolicy": {
    "name": "Overdue fine policy"
  },
  "lostItemPolicyId": "ea77439c-9ff5-4c37-8c92-0df02576c873",
  "lostItemPolicy": {
    "name": "Lost item policy"
  },
  "borrower" : {
    "firstName" : "FirstName",
    "lastName" : "LastName",
    "middleName" : "MiddleName",
    "barcode" : "102322966933815"
  },
  "loanDate": "2017-03-01T23:11:00.000Z",
  "dueDate": "2017-04-01T23:11:00.000Z",
  "checkoutServicePointId": "e9af4ba4-6801-4722-bf45-d7a49d54564d",
  "checkinServicePointId": "e9af4ba4-6801-4722-bf45-d7a49d54564d",
  "status": {
    "name": "Open"
  },
  "action": "checkedout",
  "renewalCount": 0
}

mod-patron returns a more compact response and operates on objects with the "Patron Loan Schema" which I guess is a Loan simplified for integration with Patron. We get this smaller response back:

{
  "id": "9a171a89-baca-4f1a-b2c4-d7253854864e",
  "item": {
    "instanceId": "6e024cd5-c19a-4fe0-a2cd-64ce5814c694",
    "itemId": "7d9dfe70-0158-489d-a7ed-2789eac277b3",
    "title": "Some Book About Something",
    "author": "Some Guy; Another Guy"
  },
  "loanDate": "2018-06-01T11:12:00Z",
  "dueDate": "2525-01-01T11:12:00Z",
  "overdue": false
}

---

It is definitely doable to replace renewals with a mod-patron call. All we do with the response from the renewal post is to check the success status, not anything with the response data, so we wouldn't need to deal with changed data:

mylibrary/app/services/folio_client.rb

Line 103 in dbcd500

check_response(response, title: 'Renew', context: { user_id:, item_id: })

For what it's worth, we currently cancel loans using mod-circulation. See this comment:

mylibrary/app/services/folio_client.rb

Line 115 in dbcd500

# We formerly used the mod-patron API to cancel requests, but it is

We get our data on a patron's loans from graphql for display:

mylibrary/app/services/folio_graphql_client.rb

Line 338 in dbcd500

dueDate

If changing to mod-patron the response data would be marginally smaller. It could be interesting to test the response time in any case.

Another avenue would be to start using folio-graphql for mutations, thus using the same client for both display and editing of loans.