Instance record. Add ContributorType in the Instance UI
CSP Request Details
CSP Rejection Details
CSP Approved
Description
Environment
Potential Workaround
Attachments
is blocked by
relates to
Checklist
hideTestRail: Results
Activity

Cate Boerema June 18, 2018 at 10:10 AM
Hi , I am removing you from the tester assignee field on these because they need to get tested asap, as they are going out in the Q2 release and you are on vacation. You can still do PO acceptance when you get back.

Niels Erik Nielsen April 3, 2018 at 8:31 PM
So it made it into folio-testing.aws a while back. For some reason it displays a bit different there:

Niels Erik Nielsen March 24, 2018 at 12:01 AM
The contributorTypeId and the new contributorTypeText added to Instance form in a branch. To merge this branch, the back-end change must be merged first:

Niels Erik Nielsen March 22, 2018 at 12:35 PM
Thank you for the mock-up .
With that, if you have a contributor that has contributed in multiple ways, you would add a line for each contribution.
This is what we suspect will give fewer challenges if we ever want to search on contributor name + type.
I think we have consensus for this structure.

Mike Taylor March 22, 2018 at 10:44 AM
At present, I believe we don't do much custom mapping from a CQL index to a specific search, rather relying on an implicit relationship between property in the JSON and the index.
Yes. That is precisely the problem.
The CQL should never be tied to the internal structure of the database. It's an abstract query format. As a thought experiment, consider dumping PostgreSQL and returning to MongoDB or something. If we're using CQL right, that's not a problem: we just implement a different CQL-to-backend translation layer.
Purpose: To qualify the Contributor element with information like: primary author, illustrator, editor etc.
Following is implemented in the Back-end ()
},
"contributorTypeId": {
"type": "string"
},
The data can be free text, so the property should be named: contributorTypeText
See wireframe: