@Tim Auger

Thank you! What is the impact/effort of a speculative change?

The impact is a reduced confidence that this will work when you come to test it in a deployed environment, similar to some of the Sierra changes we’ve made in the past

Since that comment, I’ve managed to test the API manually against Calvary Staging and compared that to what the implementation in dcb-service does, so I would no longer consider this a speculative change

When you say, “after the supplier has checked in the item and they then decide not to lend it” meaning that the supplied item should be in an in-transit state [even if they didn’t ship the item]? Then the supplying library could cancel the request and if successful, re-resolution may not work?

Yes, IIUC any transaction status after the initial placement (CREATED) will fail re-resolution

I am with you. I definitely need to test this case. Thank you

Thanks

@Marc Johnson

This change is as ready as it can be without the ability to manually experiment with the new API in an environment. It is not possible to do so in the integration environment, and I do not have access to a FOLIO tenant in staging (though you were investigating access for this)

As this change overlaps with changes required for https://openlibraryfoundation.atlassian.net/browse/DCB-1534 I have agreed with @Alex Scott to defer merging these changes (they are on this branch) until immediately prior to him starting the relevant work for this feature. This gives us the maximum amount of time to gain access to an environment with the correct FOLIO configuration

It can be merged, as a more speculative change, prior to this if you want for testing in staging

Thank you! What is the impact/effort of a speculative change?

@Marc Johnson Thanks for highlighting your analysis. When you say, “after the supplier has checked in the item and they then decide not to lend it” meaning that the supplied item should be in an in-transit state [even if they didn’t ship the item]? Then the supplying library could cancel the request and if successful, re-resolution may not work?

I am with you. I definitely need to test this case. Thank you

@Tim Auger I’ve been trying out the new API implemented in edge-dcb / mod-dcb for this work

In one of my tests, I got the following error when trying to update the information for a cancelled request:

I understand why it would be undesirable to update the item details for a transaction that is cancelled

I am slightly concerned about the rest of the error message: it can be updated only from CREATED status.

If supplier cancellation can happen at any point in the workflow beyond when the request is placed at the borrowing library e.g. after the supplier has checked in the item and they then decide not to lend it, then the re-resolution update might fail due to this strictness of when this API can be used

This might inform some of the scenarios you intend to use for testing this change

@Tim Auger This change is as ready as it can be without the ability to manually experiment with the new API in an environment. It is not possible to do so in the integration environment, and I do not have access to a FOLIO tenant in staging (though you were investigating access for this)

As this change overlaps with changes required for https://openlibraryfoundation.atlassian.net/browse/DCB-1534 I have agreed with @Alex Scott to defer merging these changes (they are on this branch) until immediately prior to him starting the relevant work for this feature. This gives us the maximum amount of time to gain access to an environment with the correct FOLIO configuration

It can be merged, as a more speculative change, prior to this if you want for testing in staging

Once this change is in, re-resolution should not be switched on in an environment until after the relevant versions of edge-dcb and mod-dcb , that contain this new API, have been deployed