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

[MIG] contract_sale_generation: Migration to 15.0 #847

Merged
merged 57 commits into from
Jun 28, 2022

Conversation

ntsirintanis
Copy link

No description provided.

self.contract_line._onchange_is_auto_renew()
contracts = self.contract2
for _i in range(10):
contracts |= self.contract.copy({"contract_type": "sale"})
Copy link
Author

Choose a reason for hiding this comment

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

Currently tests fail at this one line. Error:

contract/models/contract_line.py", line 452, in _check_recurring_next_date_start_date raise ValidationError( odoo.exceptions.ValidationError: You can't have a date of next invoice anterior to the start of the contract line 'Test Contract Template'
Will need to check this more. @NL66278 @thomaspaulb if you have any ideas, please shoot.

Choose a reason for hiding this comment

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

@ntsirintanis I tried to follow what happens, and somehow it's a problem with the order of the evaluation of computations.

  1. The test contract line is set to certain values, among which date_start = 2020-01-01
  2. The contract including this line is copied 10 times
  3. During copying of the contract, recurring_next_date of the lines gets recomputed correctly (2020-01-15)
  4. Something happens and recurring_next_date is now 2020-01-01, which is lower than 2020-01-15 (maybe recomputation, or goes back to cached value)
  5. The computed values are checked and it finds 2020-01-01 < 2020-01-15 and borks out

I find that this stops happening when you access self.contract_line.recurring_next_date (by printing, or just like that) before copying, so between line 98 and 99.

Somehow equivalently, @rousseldenis found in this PR that he had to call _compute_recurring_next_date(), however that specifically does not work for me.

Choose a reason for hiding this comment

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

There's another failing test on import odoo.odoo.tests in another module, I don't know how that got through CI, but it's clearly from and should be odoo.tests

Copy link
Contributor

Choose a reason for hiding this comment

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

@thomaspaulb We need first to fix the tests import errors, then, check which test(s) are failing. @ntsirintanis

@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from e0490fe to 02a5564 Compare June 21, 2022 14:56
@rousseldenis
Copy link
Contributor

/ocabot migration contract_sale_generation

@OCA-git-bot OCA-git-bot added this to the 15.0 milestone Jun 22, 2022
@OCA-git-bot OCA-git-bot mentioned this pull request Jun 22, 2022
18 tasks
@rousseldenis
Copy link
Contributor

@ntsirintanis Thanks for this.

Don't forget to make your PR's title a little bit understandable (e.g.: like your last commit)

@ntsirintanis ntsirintanis changed the title 15.0 mig contract sale generation [MIG] contract_sale_generation: Migration to 15.0 Jun 22, 2022
@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from 02a5564 to fc4bf5f Compare June 22, 2022 07:25
@@ -123,13 +123,10 @@ def _recurring_create_sale(self, date_ref=False):
self._compute_recurring_next_date()
return sale_orders

@api.model
def _get_recurring_create_func(self, create_type="invoice"):
Copy link
Contributor

Choose a reason for hiding this comment

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

@ntsirintanis Why removing this ?

Copy link
Author

Choose a reason for hiding this comment

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

Because it was removed from contract module in version 15.0, along with the generation_type field and all related methods.

Copy link
Contributor

Choose a reason for hiding this comment

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

Mmmh, that's because migration PR for 15 was created before those changes.

I'll do forwardport of changes in contract since. Wait for it

Copy link
Contributor

Choose a reason for hiding this comment

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

Arf, already done.

Could you review #776 ?

@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from fc4bf5f to cb75840 Compare June 22, 2022 07:38
angelmoya and others added 19 commits June 22, 2022 11:38
…ata (OCA#130)

* [FIX+IMP] contract: Improve usability and don't fail on wrong data

* Cron create invoices masked for avoiding silent errors
* New constraints for assuring data consistency
* UI helps for entering consistent data
* Spanish translation
* Remove double company_id field on form

* [FIX] contract_sale_generation: Adapt tests to upstream contract
* Change the method called in the view
* Complete the create_invoice method
* Bump version + authoring
* Correct bad call of method
  Small Documentation
* Add super call in python test
* FIX bad field names causing bad quantities in sale.order.line
Updated by Update PO files to match POT (msgmerge) hook in Weblate.
@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from cb75840 to 0fb4b16 Compare June 22, 2022 09:58
# then it maintains it's 'old' value.
# TODO: Research that
recurring_next_date = self.contract_line.recurring_next_date
self.assertGreaterEqual(recurring_next_date, self.contract_line.date_start)
Copy link
Author

Choose a reason for hiding this comment

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

Added these 2 lines in order to make unit tests work, and pre-commit to not complain. Need to see why this is happening though.

@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from 0fb4b16 to a2d53c1 Compare June 22, 2022 10:16
@@ -96,6 +96,11 @@ def test_cron_recurring_create_sale(self):
self.contract_line.recurring_invoicing_type = "post-paid"
self.contract_line.date_end = "2020-03-15"
self.contract_line._onchange_is_auto_renew()
# If we do not recompute recurring_next_date
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, IMHO there are still some cases that should be solved after theses changes : cd086dd

@NL66278
Copy link

NL66278 commented Jun 23, 2022

@ntsirintanis I think if a test is added for a contract with payment terms and a fiscal position, the code will be nearly completely covered and you will get rid of the last two red crosses.

dates = self._get_period_to_invoice(
self.last_date_invoiced, self.recurring_next_date
)
sale_line_vals = self._prepare_sale_line_vals(dates, order_id)
Copy link

Choose a reason for hiding this comment

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

Call keyword parm with keyword: order_id=order_id

Copy link

Choose a reason for hiding this comment

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

Actually order_id is nowhere passed to _prepare_sale_line as far as I can see. So logic and argument can maybe removed from this function and from _prepare_sale_line_vals. Can anyoint point out a use for thus argument?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is intended in order to override and force an existing order

Copy link

Choose a reason for hiding this comment

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

But if you add sale lines to an existing sale order, through a write on that order, order_id will be filled automagically. Or if somehow some code wants to use the prepared values to create the order lines, the order_id can be inserted in that code. On the other hand this is existing code and we should be carefull with changing any method signature. I was just wondering about the usecase...

from odoo.tests import Form


def to_date(date):
Copy link

Choose a reason for hiding this comment

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

This one is not uses and can be removed

Copy link
Contributor

Choose a reason for hiding this comment

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

No, but should be in each test line that uses fields.Date.to_date(

@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch 3 times, most recently from 7da94d7 to c06d773 Compare June 27, 2022 12:36
Copy link

@NL66278 NL66278 left a comment

Choose a reason for hiding this comment

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

👍 LGTM

@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from c06d773 to 5b9bf0f Compare June 27, 2022 13:38
@ntsirintanis
Copy link
Author

This PR is as green as it gets. I added some superfluous unit tests to satisfy codecov, but can't do much beyond that. Please review.

@NL66278
Copy link

NL66278 commented Jun 28, 2022

@ntsirintanis I already approved the PR. In the CodeCov there are still three red lines:
https://app.codecov.io/gh/OCA/contract/compare/847/diff
You might get rid of them (if you want) by testing:

  • That a contract without lines does not generate a sale order;
  • That if you pass an existing sale order the prepare line vals function, it fills the order_id;
  • By testing the main cron function.

I do not know how the yellow lines are counted in the percentage. It might be very difficult to get rid of those.

@ntsirintanis
Copy link
Author

@ntsirintanis I already approved the PR. In the CodeCov there are still three red lines: https://app.codecov.io/gh/OCA/contract/compare/847/diff You might get rid of them (if you want) by testing:

* That a contract without lines does not generate a sale order;

* That if you pass an existing sale order the prepare line vals function, it fills the order_id;

* By testing the main cron function.

I do not know how the yellow lines are counted in the percentage. It might be very difficult to get rid of those.

Agreed. I've been already working on points one and two. Will finish them, push, and hope for absolute greenness.

@ntsirintanis ntsirintanis force-pushed the 15.0-mig-contract_sale_generation branch from 5b9bf0f to dc07e6d Compare June 28, 2022 08:57
@rousseldenis
Copy link
Contributor

@ntsirintanis Is this ready ?

@ntsirintanis
Copy link
Author

@ntsirintanis Is this ready ?

yes, finally, we are green!

@rousseldenis
Copy link
Contributor

/ocabot merge patch

@OCA-git-bot
Copy link
Contributor

This PR looks fantastic, let's merge it!
Prepared branch 15.0-ocabot-merge-pr-847-by-rousseldenis-bump-patch, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit 61f49e3 into OCA:15.0 Jun 28, 2022
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at cb00e34. Thanks a lot for contributing to OCA. ❤️

@rousseldenis
Copy link
Contributor

@ntsirintanis Could you check at this ? #841

I think this is related to your problem with recurring_next_date value.

@ntsirintanis
Copy link
Author

@ntsirintanis Could you check at this ? #841

I think this is related to your problem with recurring_next_date value.
thanks @rousseldenis , will check it out

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.