Skip to content
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

Closed

Conversation

open-net-sarl
Copy link
Contributor

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

@open-net-sarl
Copy link
Contributor Author

last pull request:
#868

Copy link
Sponsor Contributor

@rousseldenis rousseldenis left a 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

sale_order_line_date/__manifest__.py Outdated Show resolved Hide resolved
class SaleOrderLine(models.Model):
_inherit = 'sale.order.line'

commitment_date = fields.Datetime()
Copy link
Sponsor Contributor

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 ?

Copy link
Contributor Author

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

Copy link
Sponsor Contributor

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 ?

Copy link
Contributor Author

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.

Copy link
Sponsor Contributor

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()
Copy link
Sponsor Contributor

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) :

Suggested change
result = super(SaleOrder, self)._onchange_commitment_date()
result = super()._onchange_commitment_date()

Copy link
Contributor Author

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

@open-net-sarl
Copy link
Contributor Author

I did a new commit adding the commitment_date after the description in the sale.order document.
That's the change i initially wanted to do.

* Aaron Henriquez <ahenriquez@eficent.com>
* Serpent Consulting Services Pvt. Ltd. <support@serpentcs.com>
* Francesco Apruzzese <f.apruzzese@apuliasoftware.it>

Copy link
Sponsor Contributor

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 !

open-net-sarl and others added 2 commits June 13, 2019 13:13
Changed version in __manifest__.py

Co-Authored-By: Denis Roussel (ACSONE) <rousseldenis@users.noreply.github.com>
Copy link
Sponsor Contributor

@rousseldenis rousseldenis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review.

@rousseldenis
Copy link
Sponsor Contributor

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'.

Copy link
Contributor

@AaronHForgeFlow AaronHForgeFlow left a 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.

@rousseldenis
Copy link
Sponsor Contributor

The commitment_date is being not propagated to the stock moves.

Oops, just tested the onchange...

@open-net-sarl
Copy link
Contributor Author

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.

@open-net-sarl
Copy link
Contributor Author

I just did some changes in the code.
In the write method of sale.order.line, if one line add no commitment_date, all lines would have taken its sale.order's commitment_date.
In onchange, using comprehension list instead of a loop + append

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..
I just fixed a bug, but the rest works like in V11

@AaronHForgeFlow
Copy link
Contributor

@open-net-sarl Thank you for your improvements. There are still a couple of things missing:

  • Schedule date is still not passed to the stock moves when confirming the sales order

  • Test are calling to unexisting method:
    AttributeError: 'sale.order' object has no attribute 'onchange_commitment_date

Regards.

@AaronHForgeFlow
Copy link
Contributor

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

@rafaelbn rafaelbn added this to the 12.0 milestone Sep 22, 2019
@rafaelbn
Copy link
Member

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

@rafaelbn
Copy link
Member

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 .

@rafaelbn rafaelbn closed this Sep 22, 2019
@rafaelbn rafaelbn reopened this Sep 22, 2019
@OCA-git-bot OCA-git-bot mentioned this pull request Sep 22, 2019
54 tasks
@rafaelbn
Copy link
Member

I'm going to test this one as #703 (review) is not working and author @mpanarin is not going to work on it anymore.

Copy link
Member

@rafaelbn rafaelbn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested in runbot functionally: doesn't work

I used commitment date 1st October and this date doesn't propagate any where

2019-09-22_19-01-55

@alexeirivera87
Copy link
Contributor

I know why the SO line's commitment dates are not being propagated to stock.moves.
Must I get some permission to contribute?

Regards

@CasVissers-360ERP
Copy link

@alexeirivera87

I know why the SO line's commitment dates are not being propagated to stock.moves.
Must I get some permission to contribute?

Regards

What fix do you want to propose?

Copy link
Contributor

@RLeeOSI RLeeOSI left a 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':
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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"""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"""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

@NuriaXifre
Copy link
Contributor

@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?

@MiquelRForgeFlow
Copy link
Contributor

Superseded by #984.

@pedrobaeza pedrobaeza closed this Nov 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet