Proposal for Recommending Books to Patrons/Lists

Please note that this is a **proposal** and staff has not approved this feature.

This issue is in response to #5937.

## Problem

The problem, generalized, is that there exists either lists or collections of items and the community is expressing interest in letting others **recommend** a book to this data structure.

## Risks & Reservations

1. **Usage & Usefulness**. How many people will actually Recommend / Suggest books to a person if the feature existed? I don't know. I don't think the number is that high. I'd love information from e.g. @seabelis about how often this happens on e.g. Goodreads.

2. **Complexity & Dependencies**. Let's assume we expect it to be a sufficiently used feature to merit the engineering time investment. It seems like for such a system, stakeholders are noting they may like to receive _some_ sort of notification that a book recommendation has been made. A notification system (if not properly/minimally scoped) could be a complex and expensive dependency.

3. **Scope & Approach**. What is the right way to implement this feature to scope development time + approach; e.g. we probably can't justify building + supporting a new database table & models or a global notifications system for just this feature.

4. **Performance**. Avoid possible "read/write" risks such as an infogami document becoming huge and affecting page performance when lots of suggestions are made

## Possible Implementation?

Already, the minimal solution I can think of has some risks and lacks many of the features (like notifications) which have been requested in #5937:

A new POST endpoint in `plugins/openlibrary/api.py` for a class called `SuggestWorksFor(page, workids)` which can work for various `page` types (including Lists, Reading Logs, and pages within `/collections`). We could add a button called "Suggest a book" on the collections page to start **as an experiment**. Clicking the button would launch a javascript dialog box which asks for 1 or more work IDs (which can be entered as either comma or space separated. The `SuggestWorksFor` API would make sure these work IDs are minimally valid and then fetch the `page` via infogami (i.e. I think it's `web.ctx.site.get(pageid)`) and **append to** or **create** a property on the page called `suggestions` which is a list of objects {"submitter": "", "work": "OLW"}.

```
"suggestions": [
{"user123": "OL123W"},
{"user234": "OL234W"},
]
```

**Minimal notification** The system would probably need some way for a non-technical patron to then (a) see that for a given page -- e.g. Reading Log, List, or Collection -- that the `suggestions` field is not empty and report a number. When the page is loaded, check if the patron has permission to edit the page and if so, show the count/length of the suggestions field.

**Minimal Content Management System (CMS)** The page owner would need some way to convert suggestions into action, which is itself a large engineering effort. What does the minimal solution look like? I suppose this would be done manually at first within the JSON / yml for the page (e.g. https://openlibrary.org/collections/k-12.yml?m=edit)

### Reflections

As one can see, even the minimal solution without notifications requires a significant amount of engineering planning, clarification on a proposal which will require conversations, and has risks which still haven't been evaluated -- all this before we've obtained a clear understanding of the possible usage and value of this feature for/to patrons.

### Stakeholders

@tmanarl

Start by reading the related issue #5937 and the proposal in plugins/openlibrary/api.py, especially the suggested SuggestWorksFor endpoint and its interaction with infogami. Review the collections page entry point for the proposed JavaScript dialog. The work is not ready to implement until staff approve the feature and define its scope, notification behavior, storage approach, and content-management flow.

Written by the indexing model from the issue text.