Adds per library book un/suppression. (PP-985)

[tdilauro]

Description

Adds the ability to suppress/unsuppress book visibility at the library level in the book detail editor.

Motivation and Context

[Jira PP-985]

How Has This Been Tested?

• Manual functional tests in local development environment.
• All new and existing tests passing locally.
• CI tests for associated feature branch pass.

Checklist:

• N/A - I have updated the documentation accordingly.
• All new and existing tests passed.

[ray-lee]

Just a few comments/questions below.

[ray-lee]

LinkData is defined as:

circulation-admin/src/interfaces.ts

Lines 12 to 15 in 9401ed1

	export interface LinkData {
	href: string;
	rel: string;
	}

Why do we need anything besides href and rel in the returned object?

[tdilauro]

We might not. However, I included them because the objects that were returned previously were OPDSLinks, which do have those properties. And, if I'm remembering correctly, some of the test set/use those other properties.

[tdilauro]

@ray-lee I went back and tested the following:

const opdsLinkToLinkData = (link: OPDSLink | undefined): LinkData => {
  if (!link) {
    return link;
  }
  const { href, rel } = link;
  return { href, rel };
};

and got a failing test here:

  1 failing

  1) editorAdapter
       adapts valid OPDS entry:

      AssertionError: expected { Object (href, rel) } to deeply equal { Object (href, rel, ...) }
      + expected - actual

       {
         "href": "hide"
         "rel": "http://librarysimplified.org/terms/rel/hide"
      +  "role": "role"
      +  "title": "title"
      +  "type": "type"
       }
      
      at Context.<anonymous> (src/__tests__/editorAdapter-test.ts:140:38)
      at processImmediate (node:internal/timers:476:21)

But I could at least avoid explicitly mentioning role, title, and type here by changing the last two lines to

  const { href, rel } = link;
  return { ...link, href, rel };

Do you have a preference among these options?

1. Leave the code as it is;
2. Use the last couple of lines, as above (return OPDSLink props besides rel and href); or
3. Drop the failing test, assuming that there is no functionality that depends on those other properties being present on the object, and return on rel and href.

If I leave it as is, I can update the LinkData interface to acknowledge the presence of these other properties.

[ray-lee]

I'd probably just add the properties to the LinkData interface, so that the expectation that they are present is explicit. It sounds like we're not sure if that expectation is only in a test. If we were more sure, I'd go with option 3.

[tdilauro]

@ray-lee This one's ready for another look when you have time.

[ray-lee]

Looks good!