serials: enumeration and chronology field is incorrect in the slow issue receive

[BadrAly]

From the holdings detail view, librarian has two ways to receive the next issue:

1. quick (no editing)
2. slow (possibility to edit the issue before receiving)

If a librarian decides to use the slow receive, the Enumeration and chronology proposed in the issue editor is for the last received issue. It should be the Enumeration and chronology for the next issue.

• server: ils.test.rero.ch
• version: v.1.0.0

The Enumeration and chronology is "Vol 2012" in the editor instead of "Vol 2013"

[BadrAly]

@zannkukai after a quick analysis: A quick fix is to use the holdings.receive_regular_issue api for the slow receive instead of the item.update

[zannkukai]

@BadrAly for a slow receive we use the item ng-core editor based on Item jsonschema, we provide some arguments to the editor using the query string URL. So, I can't change the behavior of the item form submit.

Why we need to know is : why the prediction isn't well updated when the issue is created.
I will check on backend API

[zannkukai]

I just reproduce the problem with https://ils.test.rero.ch/professional/records/holdings/detail/968.
All seems right with data (https://ils.test.rero.ch/api/holdings/968 and https://ils.test.rero.ch/api/items/1664)

• When an item is created, then this method is called : https://github.com/rero/rero-ils/blob/dev/rero_ils/modules/items/api/record.py#L100
• According to data (https://ils.test.rero.ch/api/holdings/968 and https://ils.test.rero.ch/api/items/1664) all checks from

  rero-ils/rero_ils/modules/items/api/record.py

  Line 152 in 7894beb

  if item.get('type') == 'issue' and \

  should be valid. So the

  rero-ils/rero_ils/modules/items/api/record.py

  Line 156 in 7894beb

  updated_holding = holding.increment_next_prediction()

  should be called.

Why isn't it ? Or why this called failed ?
Can't reproduce this error on localhost (fresh setup, rebased on rero/dev)

[zannkukai]

Ok, all seems working fine in backend ::

• The prevision is well updated
• we called holding.update() with correct data

But, we called the update with the same dbcommit, reindex arguments than from Item.create() method (False by default). So the change isn't dbcommited using the db session was commited.
This is committed by "invenio_record_rest" (https://github.com/inveniosoftware/invenio-records-rest/blob/master/invenio_records_rest/views.py#L697) But this call, commit changes on Item, not on the holding.

A quick and dirty solution should be to force True for the call to holding.update() https://github.com/rero/rero-ils/blob/dev/rero_ils/modules/items/api/record.py#L158