Skip to content

MCBFF-192: [POC] Fix for Item Check-out issue when TLR exist for Item's Instance#1684

Open
mukhiddin-yusuf wants to merge 3 commits into
masterfrom
mcbff-192-poc
Open

MCBFF-192: [POC] Fix for Item Check-out issue when TLR exist for Item's Instance#1684
mukhiddin-yusuf wants to merge 3 commits into
masterfrom
mcbff-192-poc

Conversation

@mukhiddin-yusuf

@mukhiddin-yusuf mukhiddin-yusuf commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Purpose

Validation of the ECS Page TLR for the shared instance created through Mediated request with secure tenant and requester fails when trying to check-out an item from secure tenant the Item is associated with and when there's other ECS Hold Item Request for the different requester.

Root cause for the issue

it is described in the comment, but in short it is because of the failure to find the associated TLR Page request for the same requester the checkout is being performed by which is happening due to condition comparing the item's instanceId and request's instanceId is not working.

Here is some of the facts explaining why above mentioned condition is not working:

  • for ECS Title Requests, all Primary, Intermediate and Secondary created requests store real instance ID in instanceId field
  • for all Primary, Intermediate and Secondary requests itemId field stores same value, so no matter if it is Inventory Item's ID or Circulation Item's ID they are same
  • only Secondary request which is for data tenant stores real holding ID in holdingsRecordId, Primary and Intermediate requests store fake or DCB holding ID in holdingsRecordId which is linked with fake/DCB instance
  • when trying to check-out the Item by barcode with Secure tenant we are fetching circulation item along with DCB/fake holding and instance
  • at the same time, when fetching the requests to form requests queue we query requests by instanceId and itemId and since check-out by barcode is performed with secure tenant fetching of requests would happen by itemId as from the previous point we have fetched circulation item, so we are providing DCB 'instanceId', but in all requests we store real instanceId
  • finally, after fetching requests and having request queue, now we are dealing with request (Primary) where we have real instanceId and trying to compare it to DCB instanceId in condition

Approach

Since we are always fetching the requests by query matching either itemId or instanceId the condition makes sense when checkout happens with item owning data tenant and checking against request created in that tenant (Secondary in this case). In this case, Item we are dealing with would be real Inventory item and instance IDs would be same, in other cases we would be dealing with fake or DCB Item. If this described observation is always true for ECS Requests and unless we do not want to introduce new changes, like some new field pointing to real Instance ID in fake holding or fake instance or change in that manner, then I thought it might be a fix or workaround to add one more check into that failing condition: && !item.isDcbItem()

TODOS and Open Questions

  • Check logging

Learning

MCBFF-192

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant