[14.0][ADD] stock_vlm_mgmt: New module for 14.0

[chienandalu]

This module adds basic a management system for Vertical Lift Modules. It's thought as a simpler and more compact alternative attemp to stock_vertical_lift and all the dependencies that come with it.

TODO:

• Readme
• Tests
• Separate vendor implementations into different PRs

cc @Tecnativa TT45739

[rousseldenis]

@chienandalu Please don't use shortcuts in module name.

[rousseldenis]

Moreover, have you ever talked with @jbaudoux about the implementation ? Maybe it's a waste of time to have duplicated functionalities.

[jbaudoux]

You re-implement (or even copy-paste) concepts that already exist in well separated modules. It doesn't look simpler as you mix base concepts (like tray) with advanced webservices specific to modula driver. The module stock_vertical_lift_kardex implements the jmif driver. You should build a new stock_vertical_lift_kardex_modula module that implements the modula driver.
You can open an issue with what does not suits you in the base modules so that it can be discussed.

cc @simahawk @sebalix

[pedrobaeza]

We already studied your existing modules and they don't fit our needs, requiring a very big stack for starting to have something. There's no copy/paste here. It's ok to have several alternatives in such case and it's allowed inside OCA.

[pedrobaeza]

@chienandalu Please don't use shortcuts in module name.

mgmt is used a lot across OCA (example: helpdesk_mgmt), and VLM is an acronym.

[jbaudoux]

We already studied your existing modules and they don't fit our needs, requiring a very big stack for starting to have something. There's no copy/paste here. It's ok to have several alternatives in such case and it's allowed inside OCA.

Please share your analysis in an issue then...

The concept of tray and cell is existing in stock_location_tray and you did copy/paste instead of using existing base module. Please explain why

[rousseldenis]

As @jbaudoux said, you copied this:

[pedrobaeza]

Yes, sorry, I was not precised enough. These pieces have been extracted respecting attribution, but the main working way is changed.

[simahawk]

It's thought as a simpler and more compact

I see a lot of code here and none of the things I see looks "simpler" or "compact".

all the dependencies that come with it.

There's a very small set of dependencies in those modules.

Can you please elaborate? We can always learn something :)

We already studied your existing modules and they don't fit our needs, requiring a very big stack for starting to have something.

I'm not sure to understand what you are talking about in terms of "very big stack".
There are essentially 2 core modules that cover most of the cases.

It seems you are reinventing the wheel for apparently no good reasons because there's no explanation on how this work should be "better/simpler/easier/pick-yours" than what we have in stock_location_tray + stock_vertical_lift.

There's no copy/paste here.

I'd recommend you look better in this PR 😉

It's ok to have several alternatives in such case and it's allowed inside OCA.

That's not the point. I think it's pretty clear :)

[rousseldenis]

mgmt is used a lot across OCA

That's not necessarily a good reason 🙈

[pedrobaeza]

We will share the reasons for doing this module instead of using the existing stack next week after Spanish OCA days and Jornadas Odoo.

Anyway, it's OK if you don't like it, but we are not doing something incorrect or illegal and it's allowed in OCA to have some features duplicated with different approaches (see for example subscription_oca and contract). We are the first always trying to converge things inside OCA, but it's not possible in all the cases depending on the customer needs.

[simahawk]

We will share the reasons for doing this module instead of using the existing stack next week after Spanish OCA days and Jornadas Odoo.

Ok, cool.

Anyway, it's OK if you don't like it, but we are not doing something incorrect or illegal and it's allowed in OCA to have some features duplicated with different approaches (see for example subscription_oca and contract). We are the first always trying to converge things inside OCA, but it's not possible in all the cases depending on the customer needs.

Sure and we are not claiming that there's any infringement of any rule. The pointers regarding "copying" was more about "duplicating" what is already there... It's really about the code and the alternative solution that does not look like "simpler", but again, we lack info.

Anyway, let's put this discussion on hold and let's wait for some more insights 😉

[chienandalu]

Hi @simahawk @rousseldenis @jbaudoux thanks for your comments 🙃️ Some clarifications

The aim of this development is:

• To use a single location for each VLM to avoid rigid/complex putaway rules and to just store the internal structure of the items inside the black box VLMs are.
• To be more compact: having all the features in a single module (vendor integrations aside).
• To reduce the UX implementation overhead using Odoo core views and components.

About the main controversies and expanding on these premises 😅️:

• Copy-pasting stuff. The only thing that's borrowed from the other modules is the grid widget js code (to which of course I put the right attribution it lacked). You point to the python logic, but if you get a diff, you'll see that it has a completly different implementation:

  • The tray has its own entity.
  • The logic is completely different.
  • You'll only find similarities in the field names.
  • Even more, we plan to completly refactor (or even drop as maybe it's not that necessary for our use scenarios) the grid stuff for v16.

• Doing work twice. We don't pretend to replace your work (which is excellent IMO) but to release our own alternative as your implementation didn't fit us. I think both solutions can co-exist. A funny note: I presented this implementation in the Odoo Spanish Days this last week and a developer approached me after the talk to tell me they had yet another from the scratch implementation of VLMs for Odoo...

• Compactness. As I said, I think your implementation is perfect as it is, but we saw some overhead in the solution:

  • We wanted to stick to simple Odoo views, components and logic where stock_vertical_lift relays on the barcodes mixin logic for the VLM operations/tasks UX.
  • So the only dependency is stock vs barcodes, web_notify and web_ir_actions_act_view_reload (considering stock_vertical_lift_tray part of the main on to be fair).
  • We wanted to separate the internal structure logic to avoid that many locations. An that doesn't much complexity.
  • In the first time we didn't even consider to have a grid stuff... and we could be dropping it anyway as it adds too much complexity to our customers with little gain (if any).
  • We wanted a communication scheme. I understand the limitations you stumbled upon and how you tried to deal with them, but a direct communication scheme locking the thread until the operation is complete is working well for the moment for us.