As a librarian, I check-in an item which is requested by another patron, so that it is ready for the next patron (transit or at desk).

Tasks:

• ...

When a loan is validated, it could be "stuck" in ITEM_AT_DESK (after transit or not) because the patron never picked up the item.

Create a recurrent task to check for this case and take actions on it (delete? Warn user?)

As a patron, I request an unavailable item (already in a circulation process - request, loan, ...), so that I can then borrow it.

In the file transitions.py, the class ItemInTransitHouseToItemReturned:

should be
"super(ItemInTransitHouseToItemReturned, self).after(loan)"

instead of
"super(ItemOnLoanToItemReturned, self).after(loan)"

As a user, I can be notified when loan changed

Tasks:

• #52 Loan notifications

As a librarian, I extend the duration of a loan for a given patron, so that he has more time.

Tasks:

• ...

Implement notifications as a signal whenever a loan changes state.

Create endpoint to give back circulation_status given an item_pid.

As a patron, I request an available item, so that I can then borrow it.

..api.get_items_by_doc_pid imported but unused
..api.get_items_by_doc_pid imported but unused

Here https://github.com/inveniosoftware/invenio-circulation/blob/master/invenio_circulation/records/jsonresolver/item.py#L17

As a librarian, I check-out an item for a patron, so that he can take it home.

Tasks:

• Fix the tests
• #25 Create REST endpoint for checkout
• #26 Checkout: implement access restriction to the REST endpoints
• #48 Checkout: Check item availability on checkout

As a librarian, I check-in an item for a patron, so that he can return it.

• add a test for this action

blocked by #1

• create a classmethod to generate the diagram
• create a corresponding cli

As a patron, I extend the duration of a loan, so that I have more time.

Tasks:

• Create transition ItemToLoanToItemToLoan #49

As a patron, I request a document, so that I can take one of its items home (the system attributes automatically the request to an available item).

Tasks:

• ...

As a librarian, I see the circulation activity of a given patron (list of loans, requests, history).

Tasks:

• ...

Should it be loan instead?

As a librarian, I have one default circulation policy applying equally to every loan (the application of this policy can be customized: for example depending on one given patron attribute, item circulation type and item location).

Tasks:

• generate diagram from the Loan class
• extend conditions to all actions #28

As a librarian, I can cancel a request.

Tasks:

• ...

As a librarian, I check-in an item belonging to another library for a patron, so that it will be sent back to its owning library.

• Implement the check-in action taking into account the item location and any other pending loans on the item.

As a librarian, I request an unavailable item (already in a circulation process - request, loan, ...) for a given patron, so that he can then borrow it.

Tasks:

• ...

As a user, I want to know the circulation availability of an item, so that I can borrow it.

• Definition of available:
  • missing/on-binding...
  • loanable/consultation...
  • on loan (computed)

Tasks:

• #29 Create ES mapping and JSON-Schema for loan #37
• #39 Implement the validate checkout method

Implement access restriction to the action "checkout".

As a patron, I choose a pick-up library by doing a request, so that I can then borrow it.

Tasks:

• ...

As a librarian, I mark a borrowed item as lost, so that it is out of circulation.

Tasks:

• ...

• write docstring
• write documentation for the module

The purpose of this issue is to avoid exchanging emails and provide our thoughts and ideas for our solution so far and further development.

After spending some time with the existing implementation and requirements, in my opinion we are on a good phase. The solution is flexible enough to handle the cases we thought in advance, but with minor modifications can be adjusted to accommodate any further cases.

There are several user stories that can be expressed as the same query with different parameters, such as requesting available and unavailable items, or handling the same request for a patron or a librarian.

I did a pretty intensive review in the policies pull request, and after going through the pre-work, I see now what we are trying to do with the functions that try to extend policies in the utils.py. I believe we should come up with a pattern or something to provide that extendability or completely isolated under a policies.py file. Either way I believe further discussion is needed on the particular case.

All in all, it would be very nice if anybody had any ideas or thoughts that would like to put under discussion and all together take it to the next level.

Good job everybody!

As a patron, I can cancel a request I made.

• handle the case when the item is lost.

Tasks:

• ...

When loan is in state ITEM_AT_DESK and we perform the action checkout, the transition is checking is_item_available.
This function will check if the there is loan on this item, and it will return false because there is actually a loan with state ITEM_AT_DESK.

This function must be changed to exclude the ITEM_AT_DESK loan for the current patron.

Solution

The config variable CIRCULATION_STATES_ITEM_AVAILABLE = ['ITEM_RETURNED', 'CANCELLED'] was supposed to define the list of states for which an item is considered available for loan, but it is not enough and it is very hard to compute the opposite, the list of states for which the item is not available for loan, or to know the last Loan state of an item.

The proposed solution is to replace this config with the opposite, something like:
CIRCULATION_STATES_ITEM_ON_LOAN = ['ITEM_AT_DESK', 'ITEM_IN_TRANSIT_FOR_PICKUP', 'ITEM_ON_LOAN', 'ITEM_IN_TRANSIT_TO_HOUSE']
which defines the list of states for which an item is considered currently on loan. This will ensure that it is easy to compute if given an item_pid there is an existing loan on it.
This change will require to change the methods and factories around item availability.

Implement default dummy authorization decorator for Loan actions view that can be configured in the app using the module.

Something like:

@need_view_permission('loan-actions')

Write REST endpoint

In Invenio, users are not records, and they don't have a Persistent Identifiers, but they have a user ID.

As a patron, I see my circulation activity (list of loans, requests, history).

Tasks:

• ...

Currently when you create a loan on an item the document_pid is not attached on the loan. We should enable this behaviour by automatically attach the document_pid of the item.

As a librarian, I validate a request on an available item, so that it is ready for the patron.

Tasks:

• ...

Here https://github.com/inveniosoftware/invenio-circulation/blob/master/invenio_circulation/views.py#L90 the loan links factory is retrieved from the config CIRCULATION_LOAN_LINKS_FACTORY but is never set to a default. Also should be changed to be able to be overridden by an external module like invenio-app-ils.

As a librarian, I see the loan history of a given item.

Tasks:

• ...

A JSON POST request with the following form: /loan/<pid>/<action>. Should return the updated loan object in JSON.

As a librarian, I request a document for a given patron, so that he can take one of its items home (the system attributes automatically the request to an available item).

Tasks:

• ...

When creating a loan on a document, the system automatically assigns an item when available.

We should be able to override the one automatically assigned and assign a specific valid item.

As a librarian, I request an available item for a given patron, so that he can then borrow it.

Tasks:

• ...

Create the transition ItemToLoanToItemToLoan to implement the extend trigger.

As done in app ILS, refactor permissions.py to remove permissions classes and functions that are already available on invenio-access.

As a librarian, I receive an item coming from another library, so that it is ready for the patron or it goes back on shelf.

Tasks:

• ...