[MODPATRON-40] Unexpected responses from GET /patron/account/<id> WRT the includeCharges query arg Created: 15/Jul/20  Updated: 14/Sep/21  Resolved: 14/Sep/21

Status: Closed
Project: mod-patron
Components: None
Affects versions: 4.2.0
Fix versions: None

Type: Bug Priority: P2
Reporter: Craig McNally Assignee: Kyle Felker
Resolution: Duplicate Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified
Environment:

folio-testing, fameflower production envs


Attachments: Microsoft Word MODPATRON-40-1.docx     Microsoft Word MODPATRON-40.docx     PNG File mtsu-1.png    
Issue links:
Blocks
is blocked by UIU-1773 "0" specified for "itemID" if no item... Closed
Duplicate
is duplicated by MODPATRON-59 Account lookup fails if patron has fe... Closed
Relates
relates to MODFEE-88 UUID fields should be validated again... Closed
relates to UXPROD-2754 Patron Empowerment | PATRON modules ... Analysis Complete
Requires
requires EDGPATRON-32 Make the item field in a charge not r... Closed
Sprint: Prokopovych - Sprint 123, Prokopovych - Sprint 122, Prokopovych - Sprint 121
Development Team: Prokopovych
Affected Institution:
MO State, Okanagan College

 Description   

Overview:
When calling GET /patron/account/<id>?includeCharges=true, a 404 is returned. If includeCharges is omitted or set to false, the call succeeds.

NOTE that even when omitting or explicitly setting includeCharges=false, the response includes the total charge information.

Steps to Reproduce:

  1. Log into folio-testing
  2. Find a user w/o any charges
  3. Call mod-patron w/ includeCharges=true for that user
  4. Add a fee/fine to that user
  5. Repeat the call to mod-patron

Expected Results:

user has charges includeCharges charges shown in response
yes omitted no
yes true yes
yes false no

Actual Results:

user has charges includeCharges charges shown in response
yes omitted no
yes true 404 not found
yes false no

Additional Information:

$ curl $OKAPI/patron/account/c0d4a2da-7c38-46f4-869c-797bb083ee2d -H "X-Okapi-Token: $TOKEN" -w'\n'
{
  "totalCharges" : {
    "amount" : 50.0,
    "isoCurrencyCode" : "USD"
  },
  "totalChargesCount" : 1,
  "totalLoans" : 0,
  "totalHolds" : 0,
  "charges" : [ ],
  "holds" : [ ],
  "loans" : [ ]
}

$ curl $OKAPI/patron/account/c0d4a2da-7c38-46f4-869c-797bb083ee2d?includeCharges=false -H "X-Okapi-Token: $TOKEN" -w'\n'
{
  "totalCharges" : {
    "amount" : 50.0,
    "isoCurrencyCode" : "USD"
  },
  "totalChargesCount" : 1,
  "totalLoans" : 0,
  "totalHolds" : 0,
  "charges" : [ ],
  "holds" : [ ],
  "loans" : [ ]
}

$ curl $OKAPI/patron/account/c0d4a2da-7c38-46f4-869c-797bb083ee2d?includeCharges=true -H "X-Okapi-Token: $TOKEN" -w'\n'
Not Found

This issue must also account for the following:

  • Make the "itemId" returned by fees/fines optional instead of using a "0" to indicate the field is not in use. Since an item is not required in the charge schema, the code may just work. The goal would be to have charges with no itemId return without the item field set and the other fields set if in use by FOLIO.

URL:
Interested parties:
Magda Zacharska, Anya, Ian Walls, Martin Tran



 Comments   
Comment by Craig McNally [ 15/Jul/20 ]

While the root cause of this is bad data in the account record (See UIU-1773 Closed and MODFEE-88 Closed ), ideally mod-patron would handle this more gracefully and not return a 404. For that reason I'm keeping this bug open.

Comment by Anastasiia Zakharova [ 16/Jul/20 ]

Craig McNally I see this is assigned to Gulfstream with Release:Q2 2020 Hot Fix. What's the priority of this bug? Is it urgent or not?
As we'd rather not take it right now. Team has 2 devs on vacation next week out of 4 and honestly speaking our capacity is pretty full.

Comment by Matt Reno [ 01/Sep/20 ]

The current plan is to make the "itemId" returned by fees/fines optional instead of using a "0" to indicate the field is not in use. Since an item is not required in the charge schema, the code may just work. The goal would be to have charges with no itemId return without the item field set and the other fields set if in use by FOLIO.

See the related JIRA for fees/fines for more info.

Comment by Molly Driscoll [ 30/Jul/21 ]

We are receiving reports from a live library that account access in EDS is failing when they have fees/fines on their patron account that do not have a corresponding item. They are unable to view their loans or requests. It seems as if it may be tied to this bug. Are there any plans for a fix and, if so, is there a timeline? Thanks for any info you can provide. cc: Craig McNally and Matt Reno

 

Comment by Kyle Felker [ 26/Aug/21 ]

Craig McNally

I am unable to replicate this issue on snapshot.  Procedure I followed:

1.  I added a fee of 5.00 to a user account (sheldon bazinga) with no item data.

2.  Sent a request for the patron account data to mod-patron:

http://folio-snapshot-okapi.dev.folio.org/patron/account/b4cee18d-f862-4ef1-95a5-879fdd619603?includeCharges=true

As you can see, the account data is reported in the result (I added a second 3.00 charge the same way just to make sure-that's showing as well):
{
"totalCharges":

{ "amount": 8.0, "isoCurrencyCode": "USD" }

,
"totalChargesCount": 2,
"totalLoans": 0,
"totalHolds": 0,
"charges": [
{
"chargeAmount":

{ "amount": 5.0, "isoCurrencyCode": "USD" }

,
"accrualDate": "2021-08-26T14:36:44.767+00:00",
"state": "Outstanding",
"reason": "foo"
},
{
"chargeAmount":

{ "amount": 3.0, "isoCurrencyCode": "USD" }

,
"accrualDate": "2021-08-26T14:55:13.412+00:00",
"state": "Outstanding",
"reason": ""
}
],
"holds": [],
"loans": []
}

Comment by Debra Howell [ 30/Aug/21 ]

FROM SUPPORT SIG: Should this be closed Craig McNally and Kyle Felker?

Comment by Kyle Felker [ 09/Sep/21 ]

Debra Howell

I can't replicate and I have no confirmation from anyone else that it's still a problem.  So yes?

Comment by Molly Driscoll [ 09/Sep/21 ]

Kyle Felker and Craig McNally, do we know which version this would have been resolved in? I have a library on Iris HF#3 that reported this at the end of July. (Though they may have been on HF#2 or HF#1 at that point.) Should I ask them to re-test?

Comment by Kyle Felker [ 10/Sep/21 ]

Molly Driscoll

I'm not even sure it has been resolved-all I know is I can't replicate with the provided information.

I'd ask them to retest and supply detailed instructions for replicating if it does show up.

Comment by Oleksiy_Lemeshko [ 13/Sep/21 ]

Moving it to blocking till further confirmation about it's reproducibility 

Comment by Molly Driscoll [ 13/Sep/21 ]

Oleksiy_Lemeshko Kyle Felker

Does the following help at all?

 

MODPATRON-40.docx

Comment by Lisa Sjögren [ 14/Sep/21 ]

Hi!

The error

has been reported by MTSU as well.

However, similar to what Kyle Felker notes, if I try out the call edgeUrl/patron/account/atjohnson@mtmail.mtsu.edu?apikey=edgeKey&includeLoans=true&includeCharges=true&includeHolds=true
I do get what looks like a correct response, including loan/request/fee data.

Comment by Khalilah Gambrell [ 14/Sep/21 ]

Closing as this appears to not be an issue.

Generated at Thu Feb 08 23:22:33 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.