When a invoice line is create a default layout_category_sequence was created
with a value of 0, updating the value of layout_category_id.sequence instead
of fetching it.
This operation was very slow on the invoice creation wizard
opw-741517
- Create a SO of 1000
- Create a down payment of 300, validate
- Create the final invoice
In the partner view, a total of 1600 is displayed as invoiced.
In the case of a down payment, the corresponding invoice line has an
amount with a negative sign. Since the report computes the absolute
value before multiplying by the sign, this information is lost.
The absolute value is not necessary since `price_subtotal_signed`
already includes the correct sign.
opw-741159
Mass mailing `mail templates` when selected in a mass mailing are
always used in the english version.
But when another language is involved the edition of mass mailing
`templates` had a number of issue. For example saving the edited english
would only modify the user current language.
These issues are cause because the widget with snippets used for mass
mailing templates edition is not compatible.
Several fixes were proposed, what was choosen finally was to use the
correct widget with the following behavior changes:
- the snippets are not showed anymore in mass mailing templates,
- the current language can be edited and is saved rightly,
The shortcoming this give mass mailing templates can be partly
compensated by:
- editing the template back (if someone want the old behavior),
- duplicating mass mailings which keep the snippets and translations,
- doing a customization to improve the situation
closes#16255fixes#16165
opw-726746 opw-727232
note: this fix is only needed for 9.0 and saas-11.
When creating a pad before this change these were the steps:
- modify pad URL for new pad URL
- end of record loading
This caused an issue because modifying the record at this point would
mark it as dirty before displaying it (which would result in a erroneous
warning "The record has been modified, your changes will be discarded.
Are you sure you want to leave this page ?").
With this fix:
- modifying the pad URL is done after the record is ready
- deferred have been unified (to remove possible race conditions)
closes#15239
opw-702797
forward port note: this change is needed up to saas-15, over saas-15
only a small part is needed (because x2many views are loaded with the
root view and there is one widget instance per record).
code note: it would be better to modify load_record of form view and
delay `record_loaded` upto after x2many views are loaded, but possible
impacts have been judged too risky so this is done only in pad widget.
Don't check ids with "id is None" statements, as it won't match if id is False. This caused some bugs with MRP when confirming a MO with no calendar defined, if mrp_operations was installed.
When a partner has a lot of contacts, the computation of the issue total
takes a lot of time. Indeed, it performs the computation for the
partner, but also for all the children, despite the fact that the amount
is not displayed.
opw-726355
Currently the amounts of all invoices (linked to sale or purchase
journals) is summed regardless of these invoices being bills or
refunds, this means e.g. if you create an invoice for 1000 then a
refund for 500 on this invoice, the dashboard will display an
"awaiting payment" total of 1500 which while technically correct is
not really logical or helpful from a user's POV.
Fix summation to take in account the invoice type (invoice or refund)
and remove refund amount from the total amount.
Intent validated by @lap-odoo, also not ignoring or removing refunds
from count to avoid situations like "0 Awaiting Payments [for] $-1200"
which would be really strange.
OPW-728860
To substract the included tax from the unit price when it's mapped
by a fiscal position in the POS.
To keep the same behavior introduced by this commit odoo@503820a
opw:710437
SQL that retrieves data for the "Due Payments" report doesn't include
any filter for excluding AR/AP move lines already reconciled, which
shouldn't be presented in this report.
Courtesy of Pedro Baeza. Was PR #16440
On IE (from 9.0 up to at least IE EDGE 14) we have this behavior
for the method serializeToString of XMLSerializer:
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0])
'<b xmlns="http://www.w3.org/1999/xhtml">"</b>'
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0].firstChild)
'"'
Whilst browser such as chromium or firefox have:
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0])
'<b xmlns="http://www.w3.org/1999/xhtml">"</b>'
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0].firstChild)
'"'
Hence for IE9 and over, if in a `<t t-extend/>` a `t-jquery`
sub-directive (without `t-operation`) is available, we can have
broken javascript if a " is transformed into an " at a unfortunate
location.
This commit favour node.data over XMLSerializer serializeToString to
avoid the possibility of this issue when a text node is processed.
opw-727283
When deduplicating contacts, the function _process_query doesn't use
the orm to fetch the partners to merge according to the criteria.
So there were some access error in multi company when trying to merge
contacts from a not allowed company.
Now a check is made with the orm before merging the contacts.
opw:708457
When a comma was written in the client_order_ref field of the SO,
the name of the invoice was duplicated because by default the name
of the invoice is client_order_ref in function _create_invoice defined
in model "sale.advance.payment.inv".
opw:724846
- Create a SO with a product that is a service and will be invoiced
based in delivery quantities and will be tracked on timesheets and
contract.
- Confirm
- Use a simple user that only has for rights: "Employee"
- Create a timesheet as the employee for the contract created by the sale
- Log some time
- Save it
- Check the SO: ok the number of hours should be "to be invoiced"
- Edit the timesheet and set one day to 0 hours => Access Error
In case of a zero value, the timesheet widget sends an unlink command
for the corresponding entry. In this case, the `sudo` is not set at the
appropropriate moment since the context key `force_so_lines` will resue
lines which are not defined in the `sudo` environment.
opw-728453
When you do a group by on field that is not present in the view,
this.fields contains all the model's fields, not only the ones present
in the view.
As we use the method 'has_active_field' to check if the field active is
available in the view, the value is not always correct.
To fix this we take the fields_view fields instead of fields.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/5b4f7c13f32f36d86805eb7865d8a077746181d8
Issue: when a field is computed on a new record, the record is not marked as
"being computed", and it could therefore be invalidated. The fix consists in
using the standard method that marks records before calling the compute method.
- Create 2 stockable products (A & B).
- Sell these products in the POS, but leave the qty of Product A to
zero.
- Validate and pay
- In the backend, return the products and register payment
Two pickings are created, and one of them is empty.
Products with a quantity of zero are not included in a picking.
Therefore, we should ignore them when the pickings are created.
Fixes#16292
opw-728101
Steps to reproduce:
-Create a product P with a standard price = 0 and its internal category
is in perpetual valuation
-Create a SO with an analytic account and a line with one product P
-Confirm the SO
-Create and validate the invoice
Bug: The delivered qty on the SO was equal to 2 instead of 1 because two
analytic lines are created by function create_analytic_lines with amount=0.
So in function _compute_analytic, the domain was [('so_line', 'in', self.ids), ('amount', '<=', 0.0)]
and it summed the two analytic lines for these two lines. Now analytic lines with amount=0 and linked
to a move line are summed if the they are linked to entries for an account of type "Expenses"(user_type_id).
opw:727302
Step to reproduce the bug:
1.Create a product with a customer tax(15%) for a price=100
2.Create a customer invoice with this product
3.Change the amount of the tax to 10(instead of 15)
4.Validate the invoice
5.Click on "Refund invoice"
6.Select the refund method "Modify: create refund, reconcile
and create a new draft invoice"
Bug the new draft invoice has 15 as amount of tax
Now all the taxes from the invoice when preparing the refund in function
_prepare_refund, in this it keeps all the modified taxes.
opw:726491
When a user belongs to multiple groups, and an ir.rule is applicable for some of
them, the rule is added multiple times in the domain. Just do it once. This
makes the query shorter and easier to debug.
Martin Trigaux