The problem is in the UI, not the back-end: see the newly filed issue .

Yes, there definitely a meta-issue here of how we consistently relate the high-level schema presented by a business-logic module to the Real Truth of the low-level module.

But that's for another day. For this one, I'm closing as INVALID and opening a corresponding UI issue. Thanks for clearing it up for me.

I believe so (although the backend could help out the client more in these circumstances). The client needs to send the UUID of the material type (and similarly for loan-types), names can be included (but will be ignored at the moment). If that doesn't work (it seemed to in my limited testing), please let me know.

This is one of the challenges of describing a single schema for representing an item in both read and write contexts, it means that situations like this need additional describing somewhere else (maybe we need example request documentation above and beyond the schema?).

Hugs

This makes sense. So the backend is basically functioning correctly, and the UI needs to be changed to send the new UUID – correct?

I've just tried to recreate this and couldn't. Looking at the example request:

It looks like the name of the material type has changed to DVD however the ID hasn't changed, and that is what the inventory module passes on to the inventory storage module (as it only understands IDs since the changes around controlled vocabularies).

I'm aware that this is somewhat confusing, maybe it could be useful for the inventory module to detect discrepancies between the ID and name and reject the request (with a 400 / 422 response).

If this is just the example that isn't correct, please let me know.

Hugs