Retrieve patron loans history using a REST call. The patron can see only her(his) own loans.

If you to /static/ the older jinja template are loaded. This should be removed.

Restructure api to separate concerns.

Investigate on how the librarian can create a loan possibly on a Document, to get the first available item when it is returned.

Setup email notifications for actions done on a loan

Implement loan details page as in the mockups.

• Implement a basic search for locations and internal locations
• Implement details page and add records editor

Integrate aggregation and sorting in loans search page.

Patrons (librarians?) should not be able to create/request Loans on Items if the patron has currently a Loan for the same Item.

Update item schema with mandatory circulation_status and ensure that item is re-indexed on any loan action on this item.

Create a user session with at least userPid and locationPid after login in the React app.
This is needed to perform any loan action.

Currently, they are hardcoded in the UserSession reducer initial state, and they need to be replaced with real values.

An admin should be able easily to add banners on the website for general announcements.
Currently, this is done in videos: https://github.com/CERNDocumentServer/cds-videos/tree/cdslabs_qa/cds/modules/announcements

It should be moved to an Invenio module and the front-end app should be able to fetch this configuration and display the banner.

Starting from the requirements and the existing pages for circulation, create the initial mock-ups for the back-office UI using balsamiq. Some of the mockups have been done in the past (loan page, item page) so the rest can follow a similar approach.

Integrate React-SearchKit to enable search for:

• Items
• Loans

• As user, on document page I click on a button to see the document items
• As user I request a loan (rest call to circulation)
• As user I cancel my loan(rest call to circulation)

It has been decided that Invenio config for now should be injected in the Jinja template and exposed to the JS app.

• Define get_document_by_item_pid, etc.
• Add a new endpoint to retrieve the loan status of an item

Handle _access on documents/items

• Add Patron, Librarian, Admin roles
• Add some demo data(items, location, documents)
• Add permissions per transition

Create loans history box on item details page as in the mockup
connected with #27

• account info
• past and current loans

depends on #71

A dashboard layout with proper routing to connect all our components.

GOAL
Librarian to be able to send email reminders to the patrons who exceeded the loan end date without returning the book.
System to automatically send the reminder if the book is not returned on time. Configurable variable of how frequent the celery task should be triggered.
Celery task should run every day and send reminders for loans which expire today or X days ago, where X is configurable.

Implementation
Implement rest endpoint with loanid to send the reminder to the current patron of the exceeded loan.
Implement celerybeat task
Use the celery task for sending the manual ones.

Create current pending loans box on item details page as in the mockup

Implement item details page to show all fields for an item.
Depends on #63

Integrate aggregation and sorting in items search page.

• setup sorting and aggregations in config.py
• inject configuration in react app
• integrate React-SearchKit sorting and aggregations

We need a high order component to wrap existing components that load data, and inject a loading indicator when they do so.

• Cookiecutter new instance, setup basic information
• Define the data model and create the new module repository for ILS
• Integrate the data model module in this instance.
• Setup files storage
• Create user/librarian/admin roles
• Create extensive documentation: how to use, how to customise

Front site:

• Customize home page: (responsive)
  • Create "front page collection"
  • Create sub-collections
  • Create menu
• Customize search: (responsive)
  • grid/list layout
  • row display
  • sorting
  • facets
  • pagination
• Customize record details page: (responsive)
  • different UI per type: book, volume, series with volumes, articles
  • show attached files
  • similar result section
  • share section
• Books suggestions: (responsive)
  • Define a customizable sequence of BookRequestSuggestion statuses
  • Create book request form to suggest a book and set it as PENDING
• Create a user profile page with his requests and statuses
• Help/FAQ pages

Back-office:

• Setup tools for back-office forms
• Form to create/edit/delete a simple book (responsive)
• Form to create/edit/delete a Series+Volumes (responsive)
• Files attachment
• ACL for books
• Create fixtures for demo data/user
• Suggested books:
  • Reject a book suggestion
  • Accept and create a book from a suggestion

User privacy:

• GDPR developer guide: https://techblog.bozho.net/gdpr-practical-guide-developers/

CERN CDS Overlay (to be moved):

• Create instance depending to overlay this instance
• Create the continuous integration DEV environment with local DB, ES, etc...
• Style home page
• Style search results
• Style record details page
• Style back-office forms
• Modify/add help/FAQ
• Test mobile visualization

During the implementation of resolvers several issues popped up.

• Deprecate JSONSCHEMAS_HOST, it is a dummy domain and it is used from the resolvers to avoid url conflicts with rest api. $ref properties don't work with relative urls and currently we don't have access to request to get our current host.
• There is an ongoing invenio-records-rest issue with the PID being part of the schema for create and update.
• Since CDS will wrap ILS our resolvers have to be overridable.

Change has_librarian_permission and has_admin_permission to be based on egroup.

Currently we have some modules that are almost identical. Remove duplications and move shared logic and components under shared module.

To enable the correct Invenio configuration resolution with Flavor/Overlay, this PR has to merged and the released version of invenio-config added in the setup.py.

We need a proper mechanism to handle failures and errors for the whole application

We should remove any invenio module that involves UI and we are not using, such as invenio-records-ui and invenio-search-ui.

Loan details page

• Implement stateful router to show details page when GET /library/circulation/loans/<loan_pid>
• render details page for loan (see item, patron, etc...)
• be possible to perform actions on loan
• change /backoffice view permissions to be librarian and not login_required only. Add test.
• write tests for all the ui components

• Document schema
• Item schema
• Location schema
• Document should have a list of item pids
• Item should have a document pid, location pid, status(missing, on binding, loanable), circulation(ref -> current loan or empty)

• Add a button to create a new loan for an item/patron. Currently, patron will be hardcoded and not selectable.
• Land on loan details page when loan created

Librarians should be able to see an audit log of a Loan. Proposed solutions:

• expose Loan record revisions through REST API. Drawback: queries can be very expensive due to the size of the table
• create/use an Invenio Audit feature/module to push audits to a specif ES index.

Currently, main and backoffice UI are split in 2 different React apps, so authorization is handled by backend.

We can merge together the 2 apps to simplify the development and enable several features.

This commit has been added to unblock a PR merge, but it should be reverted and fixed.

The issue is that every time an Item is indexed, it will resolve the $ref current circulation status and perform a search to find the corresponding loan. The search is done using IlsLoansSearch which is restricting the patron_pid and if you are not in a request context (like cli) you have g.identity that is None.

A solution has to be implemented to search with permissions but index correctly Items.

(related #25)

Circulation api endpoint for item state returns loan object, if loaned. This should be filtered by permissions, as not every user has permissions to see all the field of a loan (for example, the patron_pid and dates if the loan is on another user).

Tasks

• Implement a custom serializer in invenio-circulation (or in invenio-app-ils?) for Loan to show/hide/filter loan fields depending on the current logged in user, or None/fail if anonymous
• Implement a custom serializer in invenio-app-ils for Item to use the Loan serializer and show/hide/filter item/loan fields depending on the current logged in user, or None/fail if anonymous