[19.0] [MIG] contract: Migration to 19.0 #1312
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[REF] use context_today instead of time in filters [REF] Contract: split from analytic account [REF] Contract Sale Invoicing: split from analytic account [REF] Contract Sale Invoicing: update translations [IMP] - Assert that the predecessor is available for new link at uncancel [RMV] - remove usless changes [RMV] - Remove usless field recurring_invoices after the total isolation between contract model and account analytic one. recurring_invoices which was used to mark analytic account as contract became usless [IMP] - P3 syntax [IMP] - use @openupgrade.migrate() and openupgrade.logged_query [IMP] - drop transient table in migration script
[RMV] - Remove empty file [IMP] - Update no_update cron after migration [IMP] - move contract template recurrence info to line level [FIX] - Fix contract line model description [IMP] - Link contracts to analytic accounts [FIX] - Fix pylint [IMP] - Move chatter and attachments from analytic account to contract [IMP] - Move account_analytic_id to contract line level [IMP] - Improve version check in migration script [IMP] - Move contracts followers from analytic accounts [ADD] - Add mail.activity.mixin to contract.contract model remove data drop from migration scripts [12.0][FIX] - Fix _init_last_date_invoiced fix flake8 [ADD] - Update contributors list
* Remove incorrect oldname attributes. * Add filter on partners for running contracts (+ a support o2m field for that). * Cover more tables in model renaming + cleaner code using a loop. * Don't copy contract lines, but rename table + copy contract records on pre. * Contract code is now populated to "Reference/Description" field in invoice. * Order on new contract model has been restored to the same as old analytic accounts.
Currently translated at 100.0% (211 of 211 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/zh_CN/
Remove string attribute
Currently translated at 96.2% (204 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/it/
As v11 takes salesman from linked partner and now the salesman is a field in the contract that is initialized to current user, we need to assign to the recently converted contracts following old logic, or they will have admin as responsible.
Currently translated at 78.8% (167 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/de/
The lowest model access for contract.contract model is group_account_invoice group. However the addon adds two smart buttons to res.partner view without any security restrictions and without compute_sudo attribute on computed fields. This causes the view to crash when a user without the proper permissions tries to access the res.partner form view. The solution adds groups_id to the partner form views in which the buttons are added, so the only loads when the user has proper permissions. Other way to solve it would be to add compute_sudo attribute to the relevant fields, but this causes an access error when the user clicks on the smart buttons.
Currently translated at 61.3% (130 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/ca/
Currently translated at 100.0% (212 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/pt_BR/
Done through `oldname`.
Currently translated at 100.0% (212 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/zh_CN/
Currently translated at 98.1% (208 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/nl/
…s + Fix contract report
Currently translated at 99.1% (210 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/de/
Currently translated at 100.0% (212 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/es/
…tract partner label + contract company must be the same as the sale order - multi-company record rules on contract line causes performance issue - the label Partner (always False) don't make any sens - When creating a contract from a sale order the company must be the sale order company and not the user company
Don't transfer to contract those analytic accounts with the "Recurring invoicing" flag unchecked.
Currently translated at 21.7% (46 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/hr/
There were an error in previous query for moving only contracts with the mark checked, but it's also more logic to move them, but remain them disabled.
Currently translated at 22.2% (47 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/hr/
…emplate Fix this use-case: If the contract journal is not set on the contract template the contract is created without a journal when confirming the sale order
… with duplicated name - Don't execute onchange after invoice creation Using that approach (that is the current one in core) has a lot of side effects and performance bottlenecks. You can read odoo/odoo#40156 for summarizing them. This also improves the handling of the values of payment term an fiscal position for using the partner ones if not set. - Tests with duplicated name So they are not executed at all. Detected by chance looking for a test for the other PR.
- rename misnamed methods - clarify _get_recurring_next_date First compute the next period end date, then derive the next invoice date from the next period stard and end date. - handle max_date_end in _get_recurring_next_date This concentrates all next date calculation logic in one place, and will allow further simplifications. - add next period start/end fields Add two computed field showing the next period start and end date. This improve the UX and will enable further simplifications in the code. - refactor _get_period_to_invoice Move the part of the logic that compute the next period depending on the chosen next invoice date to _get_next_period_date_end.
Currently translated at 40.1% (85 of 212 strings) Translation: contract-12.0/contract-12.0-contract Translate-URL: https://translation.odoo-community.org/projects/contract-12-0/contract-12-0-contract/fr/
- REF: Refactor _update_recurring_next_date Reuse the logic that is now fully located in _get_recurring_next_date. - REF: re-add _compute_first_recurring_next_date for backward compatibility - FIX: add missing dependency in computed field - REF: remove one monthlylastday special case get_relative_delta now works the same for all recurring rules. Move the special case handling to _init_last_date_invoiced which is used only for migration. - IMP: support pre-paid for monthlylastday monthlylastday is (almost) not a special case anymore \o/. montlylastday is simply a montly period where the periods are aligned on month boundaries. The last bit of special casing is that postpaid generates invoice the day after the last dasy of the period, except for monthlylastday where the invoice is generated on the last day of the period. This last exception will disappear when we put the offset under user control. This is a breaking change because the post-paid/pre-paid mode becomes relevant for monthlylastday invoicing. The field becomes visible in the UI. Code that generate monthlylastday contract lines must now correctly set the pre-paid/post-paid mode too. Some tests have had to be adapted to reflect that. - REF: make recurring_invoicing_offset a computed field In preparation to making it user modifiable. - REF: make get_next_period_date_end public Make it public because it is the core logic of the module. Also, clarify that recurring_invoicing_type and recurring_invoicing_offset are needed only when we want the next period to be computed from a user chosen next invoice date. - REF: rename _get_recurring_next_date as get_next_invoice_date It is easier to understand. Also make it public.
This was referenced Dec 29, 2025
pedrobaeza
reviewed
Dec 31, 2025
Member
pedrobaeza
left a comment
pedrobaeza
left a comment
There was a problem hiding this comment.
Thanks, I think we are almost there.
| comodel_name="uom.category", | ||
| related="product_id.uom_id.category_id", | ||
| readonly=True, | ||
| allowed_uom_ids = fields.Binary( |
Member
There was a problem hiding this comment.
The usual convention is to name this as field_domain, which would be in this case uom_id_domain.
BhaveshHeliconia
force-pushed
the
19.0-mig-contract
branch
from
c00fcd4 to
974db1c
Compare
BhaveshHeliconia
force-pushed
the
19.0-mig-contract
branch
from
974db1c to
717adf6
Compare
Contributor
Author
etobella
reviewed
Jan 20, 2026
BhaveshHeliconia
force-pushed
the
19.0-mig-contract
branch
from
717adf6 to
44f39e9
Compare
stferraro
approved these changes
Jan 20, 2026
Contributor
|
This PR has the |
stferraro
approved these changes
Jan 28, 2026
|
@pedrobaeza please review module and approved this PR |
Member
|
@BhaveshHeliconia please include #1381 |
BhaveshHeliconia
force-pushed
the
19.0-mig-contract
branch
2 times, most recently
from
c67b25d to
70faae4
Compare
Contributor
@BhaveshHeliconia, please check the latest changes in this PR according to my comment: #1381 (comment) to preserve the |
BhaveshHeliconia
force-pushed
the
19.0-mig-contract
branch
from
70faae4 to
e44b8f7
Compare
pedrobaeza
reviewed
Jan 30, 2026
| self.env._( | ||
| "You can't have the end date before the date of last " | ||
| "invoice for the contract line '%s'" | ||
| "invoice for the contract line '%(name)s'", |
Member
There was a problem hiding this comment.
Were these changes really proposed by pre-commit? I don't think so, because when there's only one param, there's no possible order swap in the translations to require to name them. Right now, you have invalidated all the existing translations with this change.
| if not line.product_id: | ||
| line.uom_id = False | ||
| continue | ||
| if line.uom_id_domain: |
Member
There was a problem hiding this comment.
Why all these changes in the UoM handling (as well as the domain)? This doesn't require such long code. Check for example account: https://github.com/odoo/odoo/blob/42cf692eda72655be10d8519ca56baa695f28c27/addons/account/models/account_move_line.py#L846
| "login": "test", | ||
| "company_id": company2.id, | ||
| "company_ids": [(4, company2.id, False)], | ||
| "group_ids": [ |
Member
There was a problem hiding this comment.
You can use the method odoo.tests.new_test_user for simplifying this (and other user creation).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.