What does requestable mean?
What states can this be in?
What about me?

The front end should use the MVP service for items.

Required for:

• #13

Depends:

• #26

We should have:

https://api.wellcomecollection.org/item-status
 |
 ↓
https://item-status.api.wellcomecollection.org/
 |
 ↓
https://api-gateway-id.execute-api.eu-west-1.amazonaws.com/stage

The API should provide a spec in OAS 3.0 format.

We need to determine a valid spec before productionising!

As part of getting started on the requesting work, we should all be able to compile this service and run tests.

In order to properly report hold status we need to know if a hold has been placed!

We currently pass the generic API gateway error responses instead of showing the nice shiny errors from the services.

Thoughts:

Add a note saying when a person wants something. Or neededBy.

Questions

What makes an item requestable?

• It's not on the shelves

Can we not think about the cart?

What's average books person on request?

What would we want to surface on the client?

• Physical items and distinguishing features e.g. how to access them
• A status of the items requestability - is it already on hold?
• Ability to create a hold - and where the item will be available (rare reading room / library desk)

Structure

/items returns

{
"status": "on Request",
//private
"requestedByMe": true
}

In order that the item-requests services have somewhere to run they need a VPC and all that gubbins.

Currently the Catalogue API presents locations as Object typed - which is inconvenient as they cannot then be used in the stacks service.

We need to:

• Ensure a type discriminator is available for location types
• Locations should have concrete types

Required for: #26

In order to understand what client/server interactions must take place we need to understand and document the cognito auth flow in markdown in this repository.

Required for:

• #12

In order to understand if/how we are changing existing behaviour we should document existing behaviour in a markdown document in this repository.

What does appropriate feedback mean?

https://api.wellcomecollection.org/stacks/v1/status/works/:id needs to return

{
	"@context": "https://api.wellcomecollection.org/catalogue/v2/context.json",
	"type": "Work",
	"items": [{
		"id": "ys3ern6x",
		"identifiers": [{
				"identifierType": {
					"id": "sierra-system-number",
					"label": "Sierra system number",
					"type": "IdentifierType"
				},
				"value": "i16010176",
				"type": "Identifier"
			},
			{
				"identifierType": {
					"id": "sierra-identifier",
					"label": "Sierra identifier",
					"type": "IdentifierType"
				},
				"value": "1601017",
				"type": "Identifier"
			}
		],
		"locations": [{
				"locationType": {
					"id": "sicon",
					"label": "Closed stores Iconographic",
					"type": "LocationType"
				},
				"label": "Closed stores Iconographic",
				"type": "PhysicalLocation"
			},
			{
				"locationType": {
					"id": "iiif-presentation",
					"label": "IIIF Presentation API",
					"type": "LocationType"
				},
				"url": "https://wellcomelibrary.org/iiif/b16656180/manifest",
				"type": "DigitalLocation"
			},
			{
				"locationType": {
					"id": "iiif-image",
					"label": "IIIF Image API",
					"type": "LocationType"
				},
				"url": "https://iiif.wellcomecollection.org/image/L0053261.jpg/info.json",
				"credit": "Wellcome Collection",
				"license": {
					"id": "cc-by-nc",
					"label": "Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)",
					"url": "https://creativecommons.org/licenses/by-nc/4.0/",
					"type": "License"
				},
				"type": "DigitalLocation"
			}
		],
		"type": "Item",
		"status": {
			"label": "Available",
			"id": "available"
		}
	}]
}

Provide a view on "physical" items and their location on a works page.

Is this right?

https://api.wellcomecollection.org/item-requests
https://api.wellcomecollection.org/item-status

We should allow a user to request multiple items at a time to allow timely and efficient responses to a client wanting the same.

What should this look like in our API?

These were removed in trying to get a working example

Options

Request patronId from cognito on client

When authorising on the client to get the id_token used to authenticate against Cognito and API gateway, we request the patronId then.

This will then be encoded in the authorization header and the application will be able to decode it as a JWT.

• client
• login with patronID in scope
• get id_token JWT with patronID encoded
• send id_token as authorization header
• decode patronID in app`

• Proof of concept for POST /requests/works/{workId}/items/{itemId} => /users/{userId} PAYLOAD {"itemId": "12345"}

We don't need to put authentication in front of the items API (the information should be visible without logging in, at which point it's basically public).

We should deploy the items API without authentication, so that somebody can make requests and get responses.

This opens the door to the front-end starting to use this information.

The Scala service should provide the same interface as the prototype.

Required for:

• #13

In order to easily and reliably interact with the Sierra API we should make use of the Swagger client code generation capability for Sierra.

For #25

• Add Github Actions to run tests on push to branches.
• Ensure Github has the correct permissions to perform CI tasks (publish to ECR/retrieve from S3 libraries).
• Add Github Actions to publish on merge to master.

In order to demonstrate reacting to a user authenticated status we should run an experiment in the front-end that notices if a user is signed in and provides console feedback if they are.

Should we provide a mechanism to look up the status for an individual item for a particular user?

At present the client needs to request a users holds and then cross reference that with the items on a page - this causes both the API and the client to do unnecessary work.

I suggest filtering the GET /requests response with itemId, e.g.

GET /requests?itemId=abcdef

In order to easily and reliably interact with the Catalogue API we should make use of its' Swagger client code generation capability.

For #25

Users need to be authenticated with Cognito in the client:

• Create cognito user pool in catalogue account for library users
• Document intended authentication mechanism (authorization code grant with pkce): #28
• Allow user to remain signed in (browser client stores access token state for session)
• Handle refreshing client access token

Note: Are we comfortable storing the access token in the client? If we need to terminate a users access immediately how can we ensure their access tokens stop working? How can we invalidate a users access token if they are signed out?

https://github.com/wellcometrust/wellcomecollection.org/blob/master/catalogue/webapp/components/WorkItemsStatus/WorkItemsStatus.js#L59