ViewMetaData component barfs if createdBy/updatedBy users differ
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
Attachments
relates to
Checklist
hideTestRail: Results
Activity
Zak BurkeJuly 19, 2019 at 7:07 PM
As to my "I see what is happening but don't understand why" comment, here's the scoop:
I created inventory item records that had different created-by-id and updated-by-id fields and they displayed fine before my recent changes. But the process went through somehow created an item record that blew up. There used to be a function that created an array like [created-by-id, updated-by-id] and compared it to a local resource. If they differed, it would copy the array into the local resource. Changing the local resource would cause the query to fire and a new render, and at that point the array and the local resource values should have compared equal. But … they didn’t. With his record, somehow the local resource was getting [created-by-id, created-by-id] so the comparison always failed and react got stuck in a loop.
That’s what I mean by, “I see what is happening, but I don’t know why.” When I looked at the test record I created, inspecting the local resource showed it to contain [created-by-id, updated-by-id] as expected.
I was able to refactor in a way that didn’t rely on a local resource or the CDU lifecycle method. It feels cleaner, and it no longer chokes on Craig’s record. I’m still curious about why the old version failed, but not curious enough to keep debugging it since the problem is already solved.
Zak BurkeJuly 19, 2019 at 7:03 PMEdited
, I think it's unlikely that MODINV-142 is related to this ticket, but it is strikingly similar to MODUSERS-130 where is a similar problem with the created-date being set on update.
Magda ZacharskaJuly 19, 2019 at 6:57 PM
While testing this Jira I also run the scenario of creating and updating instance/item in inventory. It looks correct to me:
{
"id": "38909aeb-db2f-421e-bbae-da1e8f580bb2",
"status": {
"name": "Available"
},
"title": "Przez rozowa szybke",
"hrid": "it00000025",
"contributorNames": [],
"formerIds": [],
"discoverySuppress": null,
"holdingsRecordId": "b9b1cd37-d4bc-4f94-90cb-b1e03219212d",
"barcode": "55555777",
"copyNumbers": [],
"notes": [],
"circulationNotes": [],
"yearCaption": [],
"electronicAccess": [],
"statisticalCodeIds": [],
"purchaseOrderLineIdentifier": null,
"materialType": {
"id": "d9acad2f-2aac-4b48-9097-e6ab85906b25",
"name": "text"
},
"permanentLoanType": {
"id": "2b94c631-fca9-4892-a730-03ee529ffe27",
"name": "Can circulate"
},
"metadata": {
"createdDate": "2019-07-19T18:22:53.472+0000",
"createdByUserId": "cac3ef2e-f30e-4b44-a107-8003324f26eb",
"updatedDate": "2019-07-19T18:52:46.311+0000",
"updatedByUserId": "a997e922-6c8d-5860-b358-aceca65a62be"
},
"links": {
"self": "http://folio-snapshot-okapi.aws.indexdata.com/inventory/items/38909aeb-db2f-421e-bbae-da1e8f580bb2"
},
"effectiveLocation": {
"id": "fcd64ce1-6995-48f0-840e-89ffa2288371",
"name": "Main Library"
}
}
Sobha DuvvuriJuly 19, 2019 at 6:40 PM
: Thanks for fixing this issue. We also filed another one https://folio-org.atlassian.net/projects/MODINV/issues/MODINV-142?filter=allopenissues where when we update an item in Inventory - both "createdDate" and "updatedDate" get set to the current timestamp. Is that also possibly a UI issue or is this a backend issue? Thanks!
Magda ZacharskaJuly 19, 2019 at 6:18 PM
Verified against folio-testing - works as expected:
{
"id": "55777f06-5b05-4232-861e-853475b68ae5",
"status": {
"name": "On order"
},
"title": "MAN IN THE HIGH CASTLE.",
"hrid": "it00000030",
"contributorNames": [
{
"name": "DICK, PHILIP K"
}
],
"formerIds": [],
"discoverySuppress": null,
"holdingsRecordId": "26286a5e-28e1-4999-8c5b-e23ca609804c",
"barcode": "88660011",
"copyNumbers": [],
"notes": [],
"circulationNotes": [],
"yearCaption": [],
"electronicAccess": [],
"statisticalCodeIds": [],
"purchaseOrderLineIdentifier": "5b0b6961-d0c2-470c-b780-8b4e8e82ce79",
"materialType": {
"id": "1a54b431-2e4f-452d-9cae-9cee66c9a892",
"name": "book"
},
"permanentLoanType": {
"id": "2b94c631-fca9-4892-a730-03ee529ffe27",
"name": "Can circulate"
},
"metadata": {
"createdDate": "2019-07-19T14:03:22.054+0000",
"createdByUserId": "a4539309-1cb2-47c2-bfc4-4a2a0ed7a303",
"updatedDate": "2019-07-19T17:30:09.117+0000",
"updatedByUserId": "cf4d9b7f-00cb-5ede-a9f5-38feb11e3a5c"
},
"links": {
"self": "http://folio-testing-okapi.aws.indexdata.com/inventory/items/55777f06-5b05-4232-861e-853475b68ae5"
},
"effectiveLocation": {
"id": "53cf956f-c1df-410b-8bea-27f712cca7c0",
"name": "Annex"
}
}
Overview
This was discovered in the context of inventory, but may also impact other apps - when a record is created by one user and later updated by another user, the ViewMetaData smart component recursively calls the users API until react's nested update limit is reached, resulting in an invariant violation #185.
Reproducer
Setup:
Place an order via edge-orders - this will create an instance, holding, items as the 'diku' institutional user (NOT the diku_admin user)
At this point you can view the order, and click through to inspect the created instance/holding/items. The item record can be seen to be created and updated by the same user (diku, which doesn't have first/last name so it looks a little funny in the recording). As soon as I update the item (e.g. add a barcode, change the status - anything) I'm unable to view the record because the ViewMetaData issue described above.
It's thought that https://github.com/folio-org/stripes-smart-components/blob/2c7f2b381c154e2a027dec991450b127a2736a2a/lib/ViewMetaData/ViewMetaData.js#L73 may be the culprit here. When viewing the network trace you can see that the results from the users query comes back in the opposite order than what is expected, i.e. createdByUserId first, updatedUserId second in the array of users returned.
Note: In order to keep the reproducer number of steps to a minimum, edge-orders was used. In theory you'd get the same behavior if you manually created a new user, assigned them the needed perms, and manually created an item, then logged in as a different user and updated that same record.