search

OCA / rma

Odoo for Return Merchandise Authorization (RMA)
GNU Affero General Public License v3.0
78 stars 206 forks source link

Porting crm_claim_rma to v8 #20

Closed mistotebe closed 2 years ago

mistotebe commented 9 years ago

It seems we will need this module for 8 anyway, so I'm setting up a ticket to track the progress here.

I intend to proceed in several stages with separate pull request for each if you don't mind:

There is one thing I need to know before I start: product_warranty is still licensed under GPLv3, I am not sure if, as a non-member, I am allowed to propose a pull request relicensing the module to AGPLv3?

Also, new API+odoo code guidelines are a must now for acceptance or is a simpler port not using the new API acceptable?

mistotebe commented 9 years ago

Porting in progress:

I am not sure how to go about picking creation, whether to set up a route+picking type per warehouse and try to use procurements to drive the entire picking process or just create a picking manually or something in between as I'm not sure what the intent was behind the new stock system and have not seen a module that actually taps into it in this way

sebastienbeau commented 9 years ago

Hi thanks for the work, regarding the licence as Akretion is one of the original author I am totally agree for moving under AGPL-v3 ! (I have not idea why it's under GPL, pretty sure it's due to a bad copy paste...) @jgrandguillaume are you ok for moving under AGPL-v3?

mistotebe commented 9 years ago

Porting ~finished, see above for pull requests.

eltjor commented 9 years ago

Hi thanks for putting the effort in to port this module to v8.0. Is there a timeline for when the it will be complete?

mistotebe commented 9 years ago

This module is feature complete and has been successfully deployed in production environments since (hence some improvements made in the past months).

See limitations in the README and consider your procurement/stock routing set-up which has become too powerful in 8.0 for this module to properly interact with for more complex cases (without unduly expanding its scope and size). Also, bear in mind that while I do not expect there to be much in terms of migration from 7.0, it has not been attempted yet.

Also, I have no idea what the community's stance is on this port vs. the port by Vauxoo that has been proposed (in #26) after I have published mine. Usually, the reasons that a proposal does not get merged boil down to the shortage of reviewers, please consider helping with that if you can.

pedrobaeza commented 9 years ago

Well, this is the third port of the module _crm_claimrma, so this is some kind of crazy. Vauxoo, Eezy and you should collaborate to give a unified PR with all the possible enhancements.

mistotebe commented 9 years ago

@pedrobaeza: Wow, there is third now? I was only aware of #26...

When I created this call for help, there has been no response until code has actually been written and proposed for merging. Need to ping @nhomar and maybe we can get some closure.

@nhomar: can you give #24 a go and maybe list the use cases you think yours handles better in #26 or the requirements not handled there that are essential for you and need to be addressed in crm_claim_rma itself and not any dependant modules? I will try and do the same.

pedrobaeza commented 9 years ago

As yours is the oldest, it should be treated as the preferred one, but @nhomar said that they have improved a little all, so maybe you can try a merge of his work in yours. What do you think?

mistotebe commented 9 years ago

I will have to take a look at what is covered and how. Might take a while since I knew very little about RMA processes before I started the port and might not appreciate the other modules' purpose to be able to do a quick review.

pedrobaeza commented 9 years ago

OK, any effort is appreciated. What I want is to solve this in the best possible way.

nhomar commented 9 years ago

~~Hello @mistotebe ~~ ~~ The issue is that when our customers ask us finance this migration, we didn't know about this comments (sorry my bad I didn't see it before), then we tried to migrate everythign without touch the actual functionality (between april and may) and some stuff was not approved by customer analiysis. ~~ At the end we re-do everything on new api (trying to mantain megeable compatibility). ~~ You will be able to see the use cases in the list of tests and let me translate from spanish the user Stories in user side. ~~ And then here we are 3 iterations done by us in our repository to fix everything with the bless of the end user already. ~~ And 2 jobs re-done one here and one on ezee side. ~~ If you look in our code (which I know can have a lot of details internally but is already migrated to new api and with a bunch of unit tests) we tried to finish the migration of 100% of the repository to new api and new WMS. ~~ And as our customer asked us link everything with Logistic, we added such cases also. ~~ That's our actual situation, sadly I had short deadlines and we tried to make everything mergeable and tested to manage only 1 public effort in our side to join the job to the OCA, I can not as you see now expend X more months waiting to have them mergeable, we (vauxoo) sadly have 2 options: ~~ 1. Use as it is to move on in the next 20 or 30 features we need to develop. 2. Make a first merge as it is in order to start the process of officialize some job and use the "stable version" in our side. ~~ Why I am affronting this situation? ~~ Because even if we split the job we use a "blessed" version of everything and we are too close to deploy in production, one time we deploy in production I can not affront the job to migrate afterwards from Vauxoo's version to OCA's blessed version, on this point one time we (vauxoo) decide what to do on this moment that will be the version we will use/promote. ~~ Why am I so so insitent on that OCA use our version and not others?. ~~ Let me share with you how is the customer (not names simply the use case). ~~ This customer is a huge Electronic Seller with a huge amout of Parts Customer claimes, usage of serials, AND everything related with 3 internal process Supplier warranty, Its own warranty and QA and repairs. ~~ As you can see it will be really difficult to find a customer with more cases of study where is open to share every single effort to public releases. ~~ Then conclusions about the next steps can be done in the PR I think we are checking how is the best way to manage this situation. ~~ Regards.

A complete version of this message can be seen here:

https://github.com/OCA/rma/pull/26#issuecomment-126948334

github-actions[bot] commented 2 years ago

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.