New common based on new common infrastructure (base, uom, product, sales
team).
* Conversion of existing tests to use the common
* Remove invoicing tests common dependency when not needed (overkill
setup for most tests)
* Move tests to the correct test file.
* Rename test_sale_pricelist into test_sale_prices and add tests to
improve coverage of price computation.
* new file test_controllers to regroup all tests covering the routes.
* Speed up tests setup by creating records in batch
* Reduce tests setups and use more the common tests data.
Part-of: odoo/odoo#96791
This PR is part of the whole migration of the sale javascript
code and related code to the owl framework.
Why: better developmet framework for javascript code in odoo.
This PR in particular targets the progressbar of sales team
appearing on the CRM app.
Task - 2918635
closesodoo/odoo#95565
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
_* sale_management,sale_stock
Steps to reproduce:
- Install eCommerce
- Enable at least one more language
- Get an attribute with translations done (creation mode : never)
- Get a product with this attribute
- Go to the shop and add the product to the cart
- Go to the summary page and change the language
- Attributes fields aren't translated
Explanation:
This commit reverts the fix commit 47777ce1a7ee189c9328f53143abe492e861779e
that set the language of this description variants in function
of the order partner lang. We move where the language is added
in the context so that other cases like website_sale still have
the right translations.
opw-2790240
closesodoo/odoo#96811
X-original-commit: 9d3ffc9a1d817313764bc4b94f75711fd753fbc3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When a customer paid for an invoice linked to an SO and the transaction
was authorized, the badge 'Waiting Payment' would still be shown on the
list of linked invoices in the portal view of the SO. Since authorized
transactions are considered as confirmed payments, the 'Authorized'
badge is now shown instead.
task-2527323
Part-of: odoo/odoo#78843
The `sale.report` `paid` state is added in `pos_sale` and shouldn't be considered in the standard `sale` code.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#96125
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, orders were not confirmed when there was more than
one transaction linked to them, regardless of their state.
As of now, we check if there is only one confirmed transaction (meaning
that the state of the transaction is either 'authorized' or 'done').
Fix 4d2b04a843
task-2906040
closesodoo/odoo#95443
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When `sale` is installed alone,
the test fails because it changes the field `product_uom`
which is invisible in the view because the user executing the test
doesn't have the appropriate group.
```
FAIL: TestSaleOrder.test_fiscalposition_application
Traceback (most recent call last):
File "/data/build/odoo/addons/sale/tests/test_sale_pricelist.py", line 292, in test_fiscalposition_application
line.product_uom = uom
File "/data/build/odoo/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```
closesodoo/odoo#95910
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
On creating Invoice for an SO, Odoo checks for available bank records for the
partner and if there few of them, it chooses the first one.
However, the first one might be from another company, which leads to
"Incompatible companies error". It may happen when user works with several
companies (few active companies in the company switcher).
Fix it by filtering available bank records by company
opw-2745339
closesodoo/odoo#95790
X-original-commit: 2617772f07a77375b49a64a8e379ffe1d6f450dd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Fix some uncommon nightly error on the runbot where a race condition
happened when the tour finished too soon. The test is successful but
during the browser cleanup, things are still happening.
task-2832564
closesodoo/odoo#91920
Related: odoo/enterprise#27600
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
This commit does a couple of small related improvements:
- adds new delivery options: "Local Delivery".
We replace the existing "Normal Delivery Charges" with the new "Local
Delivery" since it is now redundant.
- Originally a "Local Pickup" demo option was going to be added, but
this appeared redundant with the "[On Site Pick]" added in
odoo/odoo#87636 . Regardless, an additional `carrier_description`
field has been added so users can include extra instructions (e.g.
address to pick up from, when pickup can occur, etc) to sales orders/
confirmation emails (emails only via ecommerce sales).
- adds option to filter based on zip prefix rather than the previous zip
"range" option, which was too restrictive in some cases (e.g. in the
UK where zips can have letters in them). Note that users can view/edit
zip prefixes in menu under settings when debug mode is active. Note:
- prefixes are ordered by name so its easier to read large numbers
prefixes
- prefixes are always capitalized to avoid duplicate prefixes that
differ by case + avoid capitalizing all prefixes every time the
`_match_address` logic is called
Task: 2706451
Upgrade PR: odoo/upgrade#3384closesodoo/odoo#84620
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In base, when the group "group_partner_manager" is created, user_root &
user_admin are already specified as group users.
Therefore, it's useless to add them again in the data of the crm & sales
modules.
Part-of: odoo/odoo#94704
Steps to reproduce:
1- install sale, invoicing
2- create a product p with price pr
3- create a new Sales Order SO with p and edit the price
to any other price than pr
4- create an invoice
5- go to SO, reduce quantity to 0 ( customer returns the item )
6- the unit price is set back to pr and there is no way to edit it
Bug:
in 836f463c97 the `_compute_price_unit`
method was changed from onchange to depends which caused the edits now
to be commited to memory.
While it can be beneficial for other flows, for this specific use case,
it is not
Fix:
make an exception for lines with already invoiced quantities
OPW-2830824
closesodoo/odoo#94482
X-original-commit: b77346926f634f2f06fe1b06b68835a360ae91c5
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
Rework and code cleanup of automatic invoice and auto-confirm order
flows.
task-2541188
closesodoo/odoo#72368
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Method: _find_mail_template()
Before this change, the method returned only the id of the template.
Now, it will return the template, as the method name suggests. Also, it
will simplify the method by avoiding complicated research into XML.
Code imported from #68965 that contained a new feature that was at last
abandoned.
Task-id: 2541188
Part-of: odoo/odoo#72368
Co-authored-by: Demesmaeker <edm@odoo.com>
This commit has as purpose to split the method `_is_add_to_cart_possible`
and put only the first part in another method so it can be overridden.
Issue:
The first part of the method _is_add_to_cart_possible check that the
product is active and can be sold.
The second part check if a combination is possible.
In sale_renting module, only the first part must be overridden since
second part is a common check to all product regardless if it
can or can't be sold or rent
opw-2879711
closesodoo/odoo#94373
X-original-commit: 99dc5a963002e887d5c4a9ad403e171b627d2e8a
Related: odoo/enterprise#28777
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
* Make sure discount is correctly computed, while considering the
attributes extra prices in the computation
* use available pricelist methods to compute base price
(remove duplicated code)
* use the correct pricelist method to get only the needed rule wherever
the price is not needed.
* reduce parameters exchange between SOL methods, use SOL fields
instead when needed
* do not try to compute discount when no pricelist rule was found,
there is no discount anyway
* Add docstrings, comments and use 'clear' methods name to ease
the understanding of the logic.
closesodoo/odoo#88230
Related: odoo/enterprise#28552
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
-Install sales and crm
-Apply multiteam option in crm settings
-Create a user with two teams A and B
-Create with this user a lead with team B
-From this lead create a quotation
Current behavior:
The quotation could have team A (the team of the lead is ignored)
Expected behavior:
The quotation always has team B
Problem when creating the quotation the team id is not propagated
in the context to the final function _get_default_team_id and in
this function the default context team is only check if no teams
have been found for the user, so the function always selects the
first team of the user. To solve the issue we propagate the team
id to the default function and we change it so that if the context
default team is in the user teams it is this one that is going to
be selected and no other.
opw-2830913
X-original-commit: 0b6c63f2be90928f5d6806ef489c369a1310be04
Part-of: odoo/odoo#94045
Before this commit, some element did not had id in the portal sale order
template. This commit intruduces them to allow easy override.
closesodoo/odoo#93859
Taskid: 2855699
X-original-commit: e829e4353574a1226163ba22b02d3080a8f75c69
Related: odoo/enterprise#28509
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The lack of a div container between the 'page' div and the payment
terms/note/fiscal position section made it impossible to add blocks
at the end of the report, after these elements.
opw-2885434
closesodoo/odoo#93893
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Steps to reproduce the product:
- Create a new product:
- Select “Service” type
- Go to the Sales tab:
- Select "Create a task in an existing project" in the `service
tracking` field
- the `project` field becomes visible
- Change the Type of the product to “Consumable”
- Try to save
Problem:
The field `project` remains visible and as it is a required field,
we have to fill it in before being able to save the product.
While it is a feature only for service-type products
Solution:
- The `project` field is based on the `service_tracking` field
to become invisible or not. So when the product is not of service type,
we must remove the tracking service so that the project field
becomes invisible.
- Prevent the user from changing the type of products already used in
a sale order
opw-2858064
closesodoo/odoo#93804
X-original-commit: 102951140e3f35ced8653d4bedb82b63bb2c963f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
If you made a sales with a partner wich is part of a company.
And then archive that partner and click on the sales smart button
from the company the sales from that partner wouldn't appear in
the list. The problem is the same for the invoices
Steps to reproduce:
- Install sales and contacts
- Create a sale for a partner (e.g. Edwin Hansen from Gemini)
- Archive that partner
- Go in the company view, click on sales button
- The sale from the archived partner do not appear in the
company sales list
opw-2850115
closesodoo/odoo#93587
X-original-commit: 8e46a00356a85b42078637d97ec6d0ef204f370a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
As it has no action and no children, this menu is an old ghost,
taking place in the code & database(s) for nothing.
closesodoo/odoo#93481
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Create a standard tax that is included in the product price.
Add that tax to a product and the down payment product.
Create a sales order (i.e. 1 line, 115$ total, 15% tax incl).
Create a percentage down payment invoice, i.e. 50%.
The downpayment amount will be 50% of the untaxed amount,
i.e. 100$ @ 50% = 50$ with tax already included, so actually
lower than 50%
Forward-Port-Of: https://github.com/odoo/odoo/pull/65275
opw-2858506
closesodoo/odoo#93531
X-original-commit: 9f9c73b33924b6093e550be63786640d8bbb9e79
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Sale code was recently refactored and reordered according to guidelines
but one recent task introduced new field & method in wrong places.
This commit moves it to the correct place.
closesodoo/odoo#93503
X-original-commit: 5d01a41524a7fe2803b5e016be0e098e8a4e486d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since #79093, the onchange updating taxes according to fpos was replaced by
a compute, but the dependency on the order fpos was not kept to avoid
full recomputation of taxes (& potentially other things) when SO fields
are modified.
Nevertheless, it makes sense in some flows to update the fpos after creation
of SOlines, and to want the taxes to be updated accordingly.
To provide this ability, a new button is added, following the existing logic
to update the prices & discounts when the pricelist is changed.
Task - 2865882
X-original-commit: 23ac2e09e19d3ee48018b2940e67048208b65caf
Part-of: odoo/odoo#93503
Translate the product name "Down payment"
when it is created "on the fly" from wizard.
X-original-commit: 17f460587a207d708f1b9d9a0c6d080e64f9eac8
Part-of: odoo/odoo#93249
When generating an SO, the down payment section is translated into the language
of the current user instead of the language of the partner.
Step to reproduce the issue:
1) Install the Sales module
2) Install another language (e.g.: French) and change the language of a partner
to this language.
3) Create a quotation for the partner which you just changed its language (and
confirm it)
4) Create an invoice (down payment) of 50% for example (confirm the invoice)
5) Create another invoice to complete the payment (confirm it too)
6) Go the latest invoice and print it
You should see that the "Down Payments" section is kept in English instead of
the other language (e.g. French).
Solution: The issue is simply that the translation of the concerned term is
translated using the lang of the user instead of the lang of the partner. To
fix this, we must update the current context to change the lang to the partner
language (defaulting to the user language if the partner has no lang).
The side effect is that in the frontend, the user will see this section in the
language of the partner instead of his own (which may looks as a bug).
Unfortunately, it is an inherent functionnality of reports, we cannot do it
otherwise (we have the same issue with the label of the Down Payment).
opw-2865865
closesodoo/odoo#93210
X-original-commit: 2859f2709f92f8947c1f81f52a580ad3510316eb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Reason: this fix is a patch for previous PR: https://github.com/odoo/odoo/pull/91009
As it should only depends on amount_delivery instead of fixed_price
Fix: clean the redundant condition and modify the delivery price
rendering in the else part
closesodoo/odoo#92965
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In the sale_signature tour, there was a step for entering auto mode when
signing for a payment. Since now the auto mode is selected by default,
it's not necessary to set it anymore.
task-2862209
closesodoo/odoo#92340
Related: odoo/enterprise#27793
Signed-off-by: Arnaud Joset <arj@odoo.com>
Task 2833338
Add a smart button to show origin SO/PO on invoices and vendor bills.
closesodoo/odoo#90664
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019
closesodoo/odoo#85728
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
During the payment pocalypse, new tests common were introduced. Those
commons were split into different classes to be as modular as possible
but we noticed during the following months (/year) that they weren't so
easy to understand and use.
Therefore, this commit aims to simplify those commons by removing the
core PaymentTestUtils common, integrating it in the base PaymentCommon,
and making the HttpCommon depend on the core PaymentCommon, instead of
using only the utils.
This doesn't require much changes in the tests since they all used
either the PaymentCommon or both PaymentCommon and PaymentHttpCommon.
Task - 2848326
Part-of: odoo/odoo#90716
Victor Feyens