Done through an extra field + inverse in the existing compute. This way, we have
the flexibility of auto-remove custom value if it matches the computed one + we don't
need extra changes in the rest of the code.
In a multicompany scenario where a contact belongs to a company and has contracts in several companies, if the user goes to the contact to edit anything, when saving, it will trigger the recomputation of the `commercial_partner_id` field, which gets populated to all the related contracts, and will undeniably fail with an `AccessError`.
A simple test is provided that, without the fix, fails like this:
```
2020-06-25 07:21:24,859 33 ERROR devel odoo.addons.contract.tests.test_contract: ERROR: test_multicompany_partner_edited (odoo.addons.contract.tests.test_contract.TestContract)
2020-06-25 07:21:24,859 33 ERROR devel odoo.addons.contract.tests.test_contract: ` Editing a partner with contracts in several companies works.
2020-06-25 07:21:24,859 33 ERROR devel odoo.addons.contract.tests.test_contract: Traceback (most recent call last):
2020-06-25 07:21:24,859 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/auto/addons/contract/tests/test_contract.py", line 2513, in test_multicompany_partner_edited
2020-06-25 07:21:24,859 33 ERROR devel odoo.addons.contract.tests.test_contract: ` 'parent_id': parent_partner.id,
2020-06-25 07:21:24,859 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/auto/addons/partner_autocomplete/models/res_partner.py", line 183, in write
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` res = super(ResPartner, self).write(values)
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/res_partner.py", line 570, in write
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` result = result and super(Partner, self).write(vals)
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/auto/addons/mail/models/mail_thread.py", line 321, in write
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` result = super(MailThread, self).write(values)
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/auto/addons/mail/models/mail_activity.py", line 613, in write
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` return super(MailActivityMixin, self).write(vals)
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3381, in write
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` self.recompute()
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5308, in recompute
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` target._write(dict(vals))
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3433, in _write
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` self.check_access_rule('write')
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3081, in check_access_rule
2020-06-25 07:21:24,860 33 ERROR devel odoo.addons.contract.tests.test_contract: ` + ' - ({} {}, {} {})'.format(_('Records:'), invalid.ids[:6], _('User:'), self._uid)
2020-06-25 07:21:24,861 33 ERROR devel odoo.addons.contract.tests.test_contract: ` odoo.exceptions.AccessError: ('The requested operation cannot be completed due to security restrictions. Please contact your system administrator.\n\n(Document type: Contract, Operation: write) - (Records: [101], User: 12)', None)
```
@Tecnativa TT24482
Previous related field was not accurated nor editable. Now the field is got
properly from a computed field.
Reviewing this, as the currency was taken (and it continues being taken) from the partner
pricelist if no pricelist is explicitly set, automatic price should use the same logic for
using partner pricelist.
Also remove roadmap as already attended
It happen that a company has to trigger the invoicing action to generate invoices before
the scheduled date (to print and prepare invoices documents, check invoices, etc.).
This requires technical access for end users with the risk that this represents.
This commit adds a new wizard to run the invoicing action for a given date with a helper
to see and check the contract that will be invoiced. When the manual action is called,
the system displays all created invoices.
[12.0][IMP] - log the manual invoice action in contract chatter
[IMP] - Add alink to the invoice in contract message at manual invoicing
[IMP] - Improve code
[FIX] - log message for invoice creation only when there is an invoice
[IMP] - split the manual invoice menu into to menus sale & purhcase
[IMP] - hide invoice button if there is nothing to invoice
I have detected a method that was created as redundant and with the same
technique used when preparing the line values, so better to have
everything together in the same method instead of having it spread.
If you have contracts in several companies, cron will create all of them, but
property fields will be populated with incorrect data as the taken company is
the main from the cron user (usually admin).
- Add failing test for next invoice date before the last date invoiced
- raise an error when next invoice date before the last date invoiced
- Add note field to contract
- add new option: create_new_line_at_contract_line_renew
Add a company config option to decide whether to create or to extend contract
line at renew action
- extend contract line at renewal
- improve code: unify methods argument _renew_create_line and _renew_extend_line
- 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.
- 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.
- 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.
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
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.
- 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
