tamulib / catalogservice Goto Github PK

• Date

We need to not require a Postgres database when running tests.

In some cases we are returning 400 Bad Request for bad responses due to Bad Data from the remote catalog service, such as FOLIO. This should probably catch all exceptions thrown when making and receiving a request from the catalog service, such as FOLIO.

These errors are already bubbling the message along so that our @ControllerAdvice will properly handle.
All that (should) need to be done for the existing handlers currently returning 400 is to change the 400 to a 500.
There may need to be additional work to catch all other appropriate exceptions and return a 500 that bubbles the exception message.
Update tests and documentation, accordingly.

The documentation and APIDocs need to be updated.
A "Hold" is actually a subset of a "Request".
This endpoint is returning a "Request" and may contain more than just a "Hold".

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide

• Upgrade Weaver-Webservice-Core parent and dependencies (requires Java 11)
• Upgrade all dependencies with vulnerabilities
• Upgrade tests to use exclusively JUnit5
• Passes CI (all tests if no CI configured)
• Replace deprecated code
• Provides a Dockerfile

If a certain dependency upgrade or deprecated code replacement ends up being large in size, create an issue.

Document procedure followed to do the upgrades on the app - insofar as it varies from the previously documented apps.

This will involve determining server, port, and authentication properties for connecting to a particular FOLIO instance as well as implementing the two methods that will actually retrieve raw records/holdings from FOLIO, parse, package, and return them as instances of the generalized CatalogHolding class.

All of these will include badges:

• Build
• Test Coverage
• Ensure PR checks are active

Where it is possible we should reuse workflows between repos.

This endpoint should return a full item record when provided an instanceHRID. This lookup should take and return multiple records.

Utilize the existing loans endpoint, and ensure backwards compatibility by providing default parameter values.

Have this endpoint accept sort by title, location, due date, renew status - basically any of the columns available

This endpoint will, behind the scenes, have to make a CQL request to FOLIO. Catalog Service will serve to abstract this for us.

Use the same syntax for requests to this endpoint as we are using for pageable, sortable, JPA repositories.

When taking on this solution, it will entail a card on MyLibraryService to pass the appropriate parameters and a card on MyLibraryUI for the table controls.

"/myrecord/items" (user)
GET
Get (charged) items, with charges and loans.
This will fetch the holding info by bib id, for each item.
This will build the libcat url link (or chiron url link for msl), for each item.
Such as: http://XXX/circulationActions/loans

Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
(Possibly under "charges" and "loans").
For BibId replacement, would this be the InstanceId or the ItemId for each item?
Consider: /circulation/loans
From: https://s3.amazonaws.com/foliodocs/api/mod-circulation/circulation.html
(Requires more parameters, but if the patron endpoint above is insufficient this should be sufficient, at least for loans.)
Consider: /item-storage/items
From: https://s3.amazonaws.com/foliodocs/api/mod-inventory-storage/item-storage.html
(Requires more parameters, but if the patron endpoint above is insufficient this should be sufficient.)
Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html

1. upgrade weaver
2. update auth service
3. update/verify build and ci

Update POM repositories:

    <repository>
      <id>tamu-releases</id>
      <url>https://artifacts.library.tamu.edu/repository/maven-releases/</url>
    </repository>

    <repository>
      <id>tamu-snapshots</id>
      <url>https://artifacts.library.tamu.edu/repository/maven-snapshots/</url>
    </repository>

Update Weaver Webservice Parent:

  <parent>
    <groupId>edu.tamu.weaver</groupId>
    <artifactId>webservice-parent</artifactId>
    <version>2.0.2</version>
  </parent>

This strategy will need to support retrieving all holdings by a record identifier and retrieving a single holding by record id and holding id (this second method could be synthetically generated from the first endpoint, if necessary)

"/myrecord/fines" (user)
GET
Get patron info.
Such as: http://XXX/circulationActions/debt/fines

Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
(Possibly under "charges").
Consider: https://s3.amazonaws.com/foliodocs/api/mod-feesfines/feefines.html
(This is not per user, but if not enough information is not available from the patron endpoint, then this may be needed.)
Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html

Update all tests to perform validation on the data returned by the API in the MVC tests.

"/myrecord/requests" (user)
GET
Get Request Holds.
This is getting holds that have a defined institution.
Does a POST to the provided URL.
Such as: http://XXX/YYY

Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
Consider: /circulation/requests
From: https://s3.amazonaws.com/foliodocs/api/mod-circulation/circulation.html
(Requires more parameters, but if the patron endpoint above is insufficient this should be sufficient.)
Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html

Make protocol configurable.

"/myrecord/blocks" (credentials)
GET
Get blocks for each, Voyager, Illiad, and Ares by NetID.
Such as: http://XXX/get_voyager_block.php?uin=YYY

Unable to size until we determine whether FOLIO will allow patron blocks.

https://dev.folio.org/reference/api/#mod-patron-blocks
https://s3.amazonaws.com/foliodocs/api/mod-patron-blocks/automated-patron-blocks.html

MyLibraryService ultimately needs this to construct its URLs.

The hrid needs to be available on the LoanItem Domain Model if following this approach.
An alternative is to adding this to the LoanItem Domain Model is to expose this via a separate endpoint and to, possibly, provide a separate (new) Domain Model.

The proposed name to use for this hrid is instanceHrid.

This is needed to resolve: TAMULib/MyLibraryService/issues/150.

"/myrecord/renewall" (user)
PUT
Renew all charged items for some user.
This is being renewed on a per-database basis for each/all databases.
Does a POST to the URL.
Such as: http://XXX/patron/YYY/circulationActions/loans?patron_homedb=ZZZ

Consider: /patron/account/{id}/item/{itemId}/renew
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
Consider: /patron/account/{id}/item/{itemId}/renew
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html

Archiving this card since the work has been moved to the GIFM repository issues.

After #73 #74 #76 are completed...

We will need to add a class generalizing CatalogItem, which is currently just a Map.

The GIFM Service will then be able to call predictable methods to get item data.

The MyLibraryService for renewing all charged items should just be able to:

1. Fetch all Charged items for uin.
2. For each of those charged items, get the item id.
3. Use the item id to renew the charge.

The current Domain Model for FeeFine does not have itemId included.
I would also note that instanceId is missing as well and might be important enough to add.

Then make sure all three Domain Models: Loan, FeeFine, and HoldRequest have both the itemId and the instanceId for consistency.

blocks TAMULib/MyLibraryService/issues/150

see: https://github.com/TAMULib/CatalogService/blob/f9ad7073b494088942e2d8f5dfe9fc49a5a2869f/domain/src/main/java/edu/tamu/catalog/domain/model/FeeFine.java
see: https://github.com/TAMULib/CatalogService/blob/f9ad7073b494088942e2d8f5dfe9fc49a5a2869f/domain/src/main/java/edu/tamu/catalog/domain/model/HoldRequest.java
see: https://github.com/TAMULib/CatalogService/blob/f9ad7073b494088942e2d8f5dfe9fc49a5a2869f/domain/src/main/java/edu/tamu/catalog/domain/model/LoanItem.java

This will prompt Manual Configuration of the config files while set up.

Followup #117 focusing on getting APISpecs up to date.

The README.md should be updated to include a link to this APISpecs.

Use the "discoveryDisplayName" in from the FOLIO response like this one:
{
"id" : "1d1ca55a-86a1-489b-a645-2d52742c196a",
"name" : "Evans stk",
"code" : "stk",
"discoveryDisplayName" : "Evans: Library Stacks",
"isActive" : true,
"institutionId" : "786bccb0-1795-4896-9452-a6e5bd5f28ac",
"campusId" : "addb918a-5b84-48a2-81d2-0a086948c347",
"libraryId" : "e19f62b7-5e0d-490f-b469-80a2b0940e74",
"details" : { },
"primaryServicePoint" : "3b80cfdf-438b-48c1-aadc-57965a0d7680",
"servicePointIds" : [ "3b80cfdf-438b-48c1-aadc-57965a0d7680" ],
"servicePoints" : [ ],
"metadata" : {
"createdDate" : "2022-01-06T23:55:48.360+00:00",
"createdByUserId" : "41199828-e6a3-444d-82d1-be838dea67d4",
"updatedDate" : "2022-01-06T23:55:48.360+00:00",
"updatedByUserId" : "41199828-e6a3-444d-82d1-be838dea67d4"
}
}

This is being done here: https://github.com/TAMULib/CatalogService/blob/cf9e0dd903b028dc0c58cd46bad05606c7f24b42/service/src/main/java/edu/tamu/catalog/service/FolioCatalogService.java#L525

The change will simply amount to this:
-builder.location(getText(location, "/name"))
+builder.location(getText(location, "/discoveryDisplayName"))

I forgot to change the username when I used the iriifservice Dockerfile as a baseline.

Change the username to one more appropriate, such as catalogservice or catalog.

We should probably standardize the naming scheme.
We may even want to consider going with a generic name rather than the service name to avoid needing this name to be different per docker file.

Have this endpoint accept sort by title, date requested - basically any of the columns available

When taking on this solution, it will entail a card on MyLibraryService to pass the appropriate parameters and a card on MyLibraryUI for the table controls.

"/myrecord/patron" (user)
GET
Get patron info, querying patron service.
Such as: http://XXX/AuthenticatePatronService

Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html

GIFM Service will need to be modified to retrieve records via Catalog Service API endpoints, rather than internal code.

This issue will need to be completed alongside or after:
#74

As of #83, support for coveralls is enabled.
Improve the coverage.

For example, carrell w/ barcode A14814169156 results in "renewal did not change the due date" error message.

Here are some item identifiers that can be used to track down some barcodes in FOLIO:
Carrels:
it00001652091
it00001652077
Lockers:
it00001652172
it00001652188

Once the Catalog Service has been separated into its own repository, the GIFM code should be removed and Catalog Service should now only provide catalog access.

There are already generalized API endpoints for catalog access, but they may require minor modification/additions since the new GIFM Service will now be dependent on them to generate its buttons.

Maybe due to a Java version change, VoyagerCatalogService has started losing its Voyager items right after adding them to the HoldingsRecord.

We'll be working on MyLibrary as well, so this card blocks the rest of the sprint work.

The publishing of the POJOs will occur as a Maven dependency.

Both repositories should retain the full git history.

"/myrecord/renew" (in body: href)
PUT
Renew a charged item.
Does a POST to the provided URL.
Such as: http://XXX/YYY

Consider: /patron/account/{id}/item/{itemId}/renew
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
Consider: /circulation/renew-by-id
From: https://s3.amazonaws.com/foliodocs/api/mod-circulation/circulation.html
(Requires more parameters, both itemId and userId.)
Consider: /circulation/renew-by-barcode
From: https://s3.amazonaws.com/foliodocs/api/mod-circulation/circulation.html
(Requires more parameters, both itemBarcode and userBarcode (there is a userBarcode?).)
Consider: /patron/account/{id}
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html (that link may not work)

Currently, our proxy of the renew action converts all non 200 statuses to a 500 with the general message "there was an error when trying to renew the item." We should, instead, pass the status code and error message forward to the recipient. (in the case of 422)

This should not be a blind pass-through, but explicitly accounted for per catalog implementation.

The GIFM Service requires access to this field when present to properly generate certain types of multi-volume buttons.

The Voyager equivalent is the chron field.

The version in the parent pom.xml is 2.1.0 and the service/pom.xml instead has 2.0.4.

This 2.0.4 should be changed to 2.1.0.

When the API path is incorrect, a 404 Whitelabel Error page still happens.

It would be great if we could get a more normal 404 error page by handling this particular instance, such as: http://localhost:9000/patron/1234/holdss.
With that extra s we should be getting a simple 404 not found, such as:
http://localhost:9000/patron/1234/holds

• locationCode
• location
• callNumber
• itemType
• canRenew

"/myrecord/cancel" (href)
PUT
Renew a charged item.
Does a DELETE to the provided URL.
Such as: http://XXX/YYY

Consider: /patron/account/{id}/hold/{holdId}/cancel
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/edge-patron.html
This endpoint appears to set a canceledDate, so the record will be persisted after cancellation.
Consider: /patron/account/{id}/hold/{holdId}/cancel
From: https://s3.amazonaws.com/foliodocs/api/edge-patron/mod-patron-patron.html

When outside the internal network, my connection will (correctly) timeout.
A ConnectException is being thrown, which is not being handled by the existing @ControllerAdvice.

I think CatalogService is acting as a "gateway" to OKAPI/FOLIO/etc.., so this error response feels more appropriate to me than an internal server error.

I do not think the ConnectException should be directly handled in this case because a ConnectException is too broad and we need to specifically handle Gateway Timeouts and report them. (There may be a desire to also handle all ConnectException, so this could be two distinct changes).

I am suggesting that the code that is performing a edge/okapi requests to catch ConnectException and then construct and thrown a Gateway Exception that should already be handled by the existing HttpServerErrorException advice. This would allow us to provide a more specific message, namely "Gateway Timeout", and possibly reference the service, such as:
504: Gateway Timeout while connecting to OKAPI.

The whitelabel for ConnectException in any other situation could still be handling with custom controller advice, but this would not be a Gateway Timeout and could probably be just set to an Internal Exception, such as:

    @ExceptionHandler(ConnectException.class)
    public ResponseEntity<String> parseError(ConnectException e, WebRequest request) {
        logger.error(e.getMessage());

        if (logger.isDebugEnabled()) {
            e.printStackTrace();
        }

        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
            .contentType(MediaType.TEXT_PLAIN)
            .body(e.getMessage());
    }

Once the GIFM Service (not necessarily its repo name) has been separated into its own repository, the Catalog Service code should be removed, and GIFM Service should now only provide button management and retrieval.

The CatalogService::getHoldingsById implementation for FOLIO currently accepts an instance UUID as the ID parameter.

Add the ability to retrieve the instance UUID from FOLIO when the ID parameter is an HRID, enabling the endpoint to accept either form of ID as input.