search

sul-dlss / sul-requests

Rails application for requesting materials from Stanford University Library
Other
4 stars 0 forks source link

Use a translated Symphony message codes in mailer on failed requests #1183

Open saseestone opened 3 years ago

saseestone commented 3 years ago

User requests fail in Symphony if the user already has a hold on the call number record, or already has the item checked out. In the mailer, we're using the generic error text to tell the user there was a problem ("We were unable to process your request because of a system error.") For these two message codes, we could/should be more specific about what's wrong.

Symphony message codes: 753 - "User already has this title charged out" 722 - "User already has a hold on this material"

In the mailer first line, display: 753 - "We were unable to process your request because you have this item checked out." 722 - "We were unable to process your request because you have a hold on this item."

In the mailer additional info (appears after the item info), display the same response for both message codes: 753 and 722 - "Request assistance by replying to this email, or check My Account (https://mylibrary.stanford.edu) for more information."

Jira issue: https://jirasul.stanford.edu/jira/browse/SW-3918

cbeer commented 3 years ago

Hm. 722 is currently marked as a successful error code, but this ticket doesn't indicate what we were expecting to happen: https://github.com/sul-dlss/sul-requests/pull/661

saseestone commented 3 years ago

Will check with @dlrueda and test this am. Unfortunately I looked at this a bit ago, and don't have notes on why I included 722 in the Jira ticket. SW-feedback is specific to 753.

I'm betting that we're placing the Symphony hold using the "HOLD@" pseudo so that the request doesn't fail completely. There's an edge case the user would need to see a different copy on the same call number record (but it's a SUPER edgy case.)

saseestone commented 3 years ago

Documenting here what happens with 722: it is a successful error code and can remain so.

The user receives the standard request confirmation mailer. Request status displays that there was a 722 response from Symphony, but nothing happens with the user's existing hold. Nor does Symphony get another hold placed on the item.

This all seems fine as the user has their (original) hold.

So ignore plans in the original issue for 722. But we should handle 753 better.

cbeer commented 3 years ago

Unassigning for now; talking with @saseestone , these codes are item-level and not patron-level and will need a different approach