Story: Use new API contract in the Instance Edit screen
Description
Environment
Potential Workaround
Attachments
is defined by
relates to
Checklist
hideActivity
Tetiana Kovalchuk March 22, 2024 at 11:24 AMEdited
Tested on missinglinks env.
Build version: #218
The following verified: Instance data display; Work data display (limited).
Instance update (except the following fields: Statement of Responsibility, Immediate source of acquisition note, Extent (API contract supports only “Extent“ subfield), Projected publication date (YYMM));
Updated data display on Search results screen.
Work update for some of the fields (Contents note, Summary)
The following related issues created and linked:
Test evidences attached:
Tetiana Kovalchuk March 20, 2024 at 8:25 AM
Payload which has the following 422 error in response:
Payload:
,
Punnoose Kutty Jacob Pullolickal March 19, 2024 at 5:53 PM
>> Does it fail for the same reason in other similar cases described here in comments?
There are two issues reported by bellow.
Issue 1: Failing due to the error JSON parse error: AgentContainer dto class deserialization error: Unknown sub-element - , Can you please send the API request that UI is sending to backend for this problem
Issue 2: Failing due to the error Subject under Predicate: http://bibfra.me/vocab/lite/subject - This issue will be fixed if you send subject’s ID in the request.
>> And was it described somewhere that only IDs should be sent instead of any other fields?
Yes. Please see my fist comment in the ticket
>> And IDs can be used for the existing values, right? And what should we use for new values, when a record didn’t have a field with filled value? Example: A record didn’t have “Subject“ when a user started editing it. Then he filled in “Subject“ with some value. What should we sent to BE?
Just send the “id” for both existing and new subjects in the PUT / POST request.
Siarhei Karol March 19, 2024 at 5:36 PMEdited
Does it fail for the same reason in other similar cases described here in comments?
And was it described somewhere that only IDs should be sent instead of any other fields?
And IDs can be used for the existing values, right? And what should we use for new values, when a record didn’t have a field with filled value?
Example: A record didn’t have “Subject“ when a user started editing it. Then he filled in “Subject“ with some value. What should we sent to BE?
Punnoose Kutty Jacob Pullolickal March 19, 2024 at 5:19 PMEdited
Hi ,
The request is failing since UI sends the “label” of the subjects in the request instead of “id”. UI should send “id” instead of “label” for subjects. See a valid request below
Details
Assignee
Doug LoynesDoug LoynesReporter
Punnoose Kutty Jacob PullolickalPunnoose Kutty Jacob PullolickalPriority
TBDStory Points
2Sprint
NoneDevelopment Team
CitationTestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee
Doug LoynesReporter
Punnoose Kutty Jacob PullolickalPriority
TBD
Purpose: The purpose of this story is to update frontend to use the new API contract in Instance Edit Screen
Opening an Instance for editing
When opening an instance for editing, the information pertaining to the associated work is shown in the left side of the screen.
The details shown in the work section (Red box in the attached image) should be taken from the
_workReferencesection of theGET /resource/{id}API response.Do not utilize the http://bibfra.me/vocab/lite/instantiates section of the API response for data retrieval. This section will be eliminated from the API response in the upcoming sprint.
Saving an instance
When saving an instance, send the ID of the related work by placing it in the
idfield under the_workReferencesection of thePOST / PUT /resource/{id}request payload. Only the ID of the work should be present in the request, with no additional work details required in the API payload.The http://bibfra.me/vocab/lite/instantiates section of the API payload should not be filled in by the front end. This section will be eliminated from the API schema in the upcoming sprint.