Consider developing against new black-box with inventory module
Description
Environment
Potential Workaround
Checklist
hideTestRail: Results
Activity
Mike TaylorMarch 21, 2017 at 11:01 AM
Changes made – worked smoothly.
Mike TaylorMarch 21, 2017 at 10:37 AM
Very helpful, thanks. I'll give this a shot.
Marc JohnsonMarch 21, 2017 at 10:34 AM
The inventory business logic interface is slightly stricter than the storage module (for example more properties are mandatory title, name on status, name on material type, name on location) and there are some additional properties. I believe the UI likely already complies with all of those additional validations.
The primary difference at the moment, is that the collection resources in inventory interface do not have a totalRecords property at the moment (I didn't get around to adding them, see ). I don't know if the UI uses those properties.
As far as I can tell, the item and instance collection resource API's are otherwise compatible apart from their root addresses.
I hope this helps with a little more clarity,
Hugs,
Marc
Mike TaylorMarch 20, 2017 at 5:23 PM
Can you please be more specific about what /inventory-storage APIs that I am currently using will not Just Work if I switch to invoking them on /inventory instead? All I get from your previous comment is a vague sense of impending doom
Marc JohnsonMarch 20, 2017 at 5:21 PM
I'm not sure about a strict superset. I believe they are currently very similar. This is likely to change in , though it's possible that moving to the inventory module might mean the changes happening there are easier for the UI to handle.
Hugs,
Marc
Wayne Schneider [9:30 PM] writes on the #general channel:
If I run against this rather than building and running my own back-end modules, it might get much easier to work on STRIPES-169. (And if that black-box is running both mod-users and the inventory stuff, it will make STRIPES-172 more tractable, too.)