Skip to content

Conversation

@BhaveshHeliconia
Copy link
Contributor

No description provided.

liweijie0812 and others added 30 commits October 1, 2025 13:54
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/
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/
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/
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.
…combinations for next invoicing period + simplify _get_period_to_invoice
Currently translated at 100.0% (216 of 216 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/
glitchov and others added 18 commits October 1, 2025 13:54
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: contract-18.0/contract-18.0-contract
Translate-URL: https://translation.odoo-community.org/projects/contract-18-0/contract-18-0-contract/
Currently translated at 100.0% (255 of 255 strings)

Translation: contract-18.0/contract-18.0-contract
Translate-URL: https://translation.odoo-community.org/projects/contract-18-0/contract-18-0-contract/it/
Currently translated at 98.4% (251 of 255 strings)

Translation: contract-18.0/contract-18.0-contract
Translate-URL: https://translation.odoo-community.org/projects/contract-18-0/contract-18-0-contract/sv/
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: contract-18.0/contract-18.0-contract
Translate-URL: https://translation.odoo-community.org/projects/contract-18-0/contract-18-0-contract/
…ing onchanges

When copying values from the contract template, skip assignment if the
value is already the same on the contract. This prevents triggering
unnecessary onchanges without altering the behavior.
@BhaveshHeliconia BhaveshHeliconia force-pushed the 19.0-mig-contract branch 2 times, most recently from b18f362 to 885e5a6 Compare October 8, 2025 12:17
@tishmen
Copy link

tishmen commented Oct 17, 2025

@BhaveshHeliconia can you please handle the failing tests so we can push this forward?

@BhaveshHeliconia BhaveshHeliconia force-pushed the 19.0-mig-contract branch 5 times, most recently from a38846e to c99f54f Compare October 17, 2025 03:57
@mamcode
Copy link
Member

mamcode commented Oct 27, 2025

@BhaveshHeliconia could you please re-run the CI checks?
I’ve tested locally with the latest ghcr.io/oca/oca-ci:py3.11-19.0 image, and it seems the CI is using an outdated cache because I am getting different errors from unit tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.