New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
12.0 mig sale order line date #875
12.0 mig sale order line date #875
Conversation
[FIX] Update readme to latest template
last pull request: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Code review. Some comments
class SaleOrderLine(models.Model): | ||
_inherit = 'sale.order.line' | ||
|
||
commitment_date = fields.Datetime() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't have migration script as you changed the field ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we never used this module, we just migrated what we needed.
Maybe add the attributes "old_name='requested_date'" would be enough, but we won't do the retro-compatibility fix. Sorry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, at least the old_name should be sufficent. Could you add it ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is done.
As told before, we tried to help the OCA, especially for the switzerland modules.
The process change <--> review does not apply only once but can last very long.
For that we are an enterprise, we can't spend a lot of time with reviews.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you.
The process change <--> review does not apply only once but can last very long.
For that we are an enterprise, we can't spend a lot of time with reviews.
That's a point of view/ Most of people in OCA are tied to enterprise too. IMHO code review should be part of development as you can confont to other people, get ideas, stay in touch with changes, ... many advantages. But that depends on enterprise philosophy, that's true.
@api.onchange('commitment_date') | ||
def _onchange_commitment_date(self): | ||
"""Warn if the commitment dates is sooner than the commitment date""" | ||
result = super(SaleOrder, self)._onchange_commitment_date() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All super could be simplified (not blocking) :
result = super(SaleOrder, self)._onchange_commitment_date() | |
result = super()._onchange_commitment_date() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it is a good way to do that.
I personally prefer being explicit, considering the result is the same.
Do as you want
00cb65d
to
af86d4a
Compare
I did a new commit adding the commitment_date after the description in the sale.order document. |
* Aaron Henriquez <ahenriquez@eficent.com> | ||
* Serpent Consulting Services Pvt. Ltd. <support@serpentcs.com> | ||
* Francesco Apruzzese <f.apruzzese@apuliasoftware.it> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could add yourself as contributor of course !
Changed version in __manifest__.py Co-Authored-By: Denis Roussel (ACSONE) <rousseldenis@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code review.
Work as expected on runbot. IMHO you should add a group on 'commitment_date' in views as for the field on 'sale.order'. Otherwise, field appear in lines but not on order level. Group : 'sale.group_sale_order_dates'. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commitment_date is being not propagated to the stock moves.
Oops, just tested the onchange... |
_prepare_procurement_values methods should work exactly as in V11. |
…d onchange in sale.order
I just did some changes in the code. I will try to help as much as i can in my free time, i just hope that it won't become an infinite review loop.. |
@open-net-sarl Thank you for your improvements. There are still a couple of things missing:
Regards. |
sorry @open-net-sarl there was an open PR for this module and it is much older than this one. SO better keep the other one: #703 |
Dear @open-net-sarl , we are very happy to have a new contributor. And we all thank you for this contribution. But It was a PR before yours, so the correct way to work is continuing the PR before: #703 As you can see here you can make PR to the original author #703 (comment) I just want you to understand that you could be in the same situation of @mpanarin , that nobody review your PR and after some time a new contributor like you, make the same PR despite of checking before if it was done. You question could be: and how could I know that? Well:
cc @alexey-pelykh FYI |
IMHO the interested people in having this module in v12 should contribute in #703 Thanks and feel free to comment. The most delicate thing here ( cc @jgrandguillaume ) is that I don't want to discourage @open-net-sarl but also I don't want to discourage @mpanarin . |
I'm going to test this one as #703 (review) is not working and author @mpanarin is not going to work on it anymore. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know why the SO line's commitment dates are not being propagated to stock.moves. Regards |
What fix do you want to propose? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The picking is not inheriting a scheduled date because it expects there to be a commitment date on the sale order. A possible solution would be to add an onchange to the line commitment date that sets the order commitment date if it doesn't exist. That way, there will be a date for the picking to inherit.
I would also suggest a warning message if the commitment date of a line is later than the commitment date of the order. In the case that the user wants one product to be promised later than the order itself, it will be possible, but since this is abnormal, there should be a message. In a normal situation, the order commitment date should be the same as the latest line commitment date, and the picking should be scheduled for the latest date.
The moves are not inheriting the commitment date because the module does not depend on sale_stock. Right now, sale_stock is calling super on sale.order.line._prepare_procurement_values and overwriting the changes from this module. Add the dependency and the moves will reflect the line commitment date.
if 'warning' not in result: | ||
lines = [] | ||
for line in self.order_line: | ||
lines.append((1, line.id, {'commitment_date': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lines.append((1, line.id, {'commitment_date': | |
if not line.commitment_date: | |
lines.append((1, line.id, {'commitment_date': |
Is there a reason why the order commitment date should overwrite an existing line commitment date?
If not, there is a solution to the issue with the date not propagating to picking. The reason the picking scheduled date doesn't inherit properly is because it's looking for an order commitment date. If you add an onchange to the line commitment date that overwrites order commitment date if it doesn't exist, then the picking will have a date to inherit.
@api.multi | ||
@api.onchange('commitment_date') | ||
def _onchange_commitment_date(self): | ||
"""Warn if the commitment dates is sooner than the commitment date""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"""Warn if the commitment dates is sooner than the commitment date""" | |
"""Warn if the commitment date is sooner than the expected date""" |
Comment from base sale module
@open-net-sarl I have done a functional review and it does not work. The commitment date does not propagate. Do you have in mind to continue working on this module? |
Superseded by #984. |
I took time to make the things as asked.
Hope this time it is okay.
Nb: I first wanted to add changes, that's why i did it again "properly". Finally, i did not do the changes wanted: it is still the module from 11.0 corrected, nothing was added or removed. The tests are not mine, i just took it from 11.0
Have a nice day