We should not trust arbitrary arguments from public method to compose a domain
as it is possible to inject '|' to disable filters and be able to search any
channel (mitigated by access rules).
Create a private method and use a wrapper that ignores the domain.
The use case is the following: the currency of a customer invoice (e.g.
EUR) is different from the currency of the company (e.g. USD). An
invoice is created in EUR, and a payment is done in EUR on the
receivable account which is in EUR.
Between the invoice date (e.g. 2015-01-01) and the payment date (e.g.
2015-02-01), the rate has changed. The reconciliation between the
invoice and the payment is done afterwards, for example 2015-03-01.
When the write-off related to the exchange difference is created:
- the date should be the max date between payment and invoice if the
corresponding fiscal year is not closed (otherwise, today's date).
- the amount currency on the receivable/payable account should be zero,
since the amount currency on the foreign exchange account is zero.
opw-659289
When selecting contacts from Contacts list views and clicking on
action window "Partner Mass Mailing", the 'active_domain' must be
filled in the wizard with the selecting contacts. In this way,
the right mailing_domain will be set when creating the related
mail.mass_mailing record (in addons/mass_mailing/wizard/mail_compose_message.py
in function get_mail_values).
opw:659383
Format_tz allow to format a date, but if the format was '%B', it was always January regardless lang in context
Now, it possible to use babel, to get the date in the customer language.
So:
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'fr_BE'})
will return '5/01/16 22:20'
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'en_US'})
will return '1/5/16, 10:20 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'en_US})
will return 'Jan 5, 2016, 10:20:31 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'fr_BE'})
will return '5 janv. 2016 22:20:31'
When configuring the payment acquirer with the confirmation
`at_pay_now`, meaning the sale order has to be
confirmed when clicking on the "Pay now" button, instead
of waiting for the payment confirmation,
the confirmation email wasn't not sent.
opw-665697
This revision is related to 6efc371291
The return URL parameter key has changed: The capital letters
are not the same than before.
Besides, send a dict in the `ADD_RETURNDATA` doesn't seem
to be supported by Buckaroo. We therefore no
longer uses a dict but a string to avoid problems.
opw-665697
Does not explicitly mention how static files are loaded. This will
confuse anyone who is using the documentation as a guide and not going
through the pet store example code. Feel free to edit however, as long
as it is mentioned somewhere.
fixes#9170
If anybody adds a new modal in the `then()` part of the promise, without
this code, all `.modal-backdrop` elements will be deleted, and further
dialogs will not be modal; with this, only the current modal's backdrop
will be deleted.
`default_location_dest_id_usage` on `purchase.order` is
used only for an attrs domain on the field
`dest_address_id` in the purchase order form.
There is therefore no worries to set it as readonly,
it won't break the feature he has been added for.
Besides, this will prevent the useless write of the
same field value on the related `stock.location`
when saving the purchase order.
This is important to prevent the useless write
on `stock.location`, as users might have the rights
to create/edit purchase orders without having
the write access to the stock locations.
opw-660736
We have taxes on pos.order.line and we have taxes on the product of the
`pos.order.line`. There was no real consensus in the POS about which
taxes to use. As long as they're the same it doesn't cause issues, but
if someone where to change the taxes on a product which is used in an
open `pos.session` things will start going wrong.
When closing the pos.session amount_total of the `pos.order` in question
will not equal tax `account.move.lines` + product
`account.move.lines`. The reason for it is that we use the taxes on the
`pos.order.line` for the tax account.move.lines, whereas amount_total
used the taxes on product.
This fixes the problem by always using the tax set on
`pos.order.line`. This tax should be set only once through
`_order_line_fields` during orderline creation. After that it shouldn't
change. Therefore `pos.sessions` won't be affected by changes to taxes
of products anymore.
opw-660765
The default domain set in _compute_analytic didn't allow to recompute
SO lines linked to several analytic lines because unit_amount is always
greater or equal to zero. The idea is to recompute the quantity delivred
on SO line linked to analytic lines with amount<=0 (which means that this
is a cost for the company, an expense or a refund).
opw:660812
"total_invoiced" must only take customer invoices into account because
when you click on the button "invoiced" in the partner view form
you just see the customer invoices.
opw:665574
Remove fixed width for kanban records in .o_kanban_mobile (in grouped
view the records overflowed their columns).
Note: this class seems useless and wrongly used by templates. This
should be removed in master (remove the class from templates and
include its less rules in all kanban records for specific classes).
"//div[@class='o_my_sidebar']" is not valid and fails when evaluated.
Could have been replaced by "//div[contains(string(@class),"o_my_sidebar")]" but
as needs a view modification, using an id is better for future inheritance.
Fixes#10279
Commit ec949ad5 links the extra move to the Sale Order through the
procurement. To be consistent, we also have to link the extra move to
the Purchase Order.
The original issue is that any extra move is not taken into account in
the received quantity calculated.
opw-665398
Commit 64e1c28e3 introduced timezoning in resource_calendar in resource already.
This broke the stock_calendar module, but as such, the timezoning in the module
is not necessary anymore. All dates calculated from the times in the calendar
are calculated back to UTC and the results are without timezone in UTC. That way,
timezones are also not needed for calculating the leaves.
Commit 64e1c28e3 introduced timezoning in resource_calendar in resource already.
This broke the stock_calendar module, but as such, the timezoning in the module
is not necessary anymore. All dates calculated from the times in the calendar
are calculated back to UTC and the results are without timezone in UTC. That way,
timezones are also not needed for calculating the leaves.
The keep_query() function has to **keep** all or selected query parameters
or add new ones but not change them by merging those with the same name.
That unnecessary parameter merge breaks the *Change language* feature in the
website_sale module when *Website -> Customize -> Product Attribute's filters*
is enabled and there's 2 or more select type attributes created and at least
one of them is selected.
Merging params was added in:
* 8.0: commit 7759af7c4c
* 9.0: commit daf8bdf688
`event_sale` adds an onchange on the `product_id` of the
sale order lines, which returns values for the fields
`event_type_id` & `event_ok`, which are used for an attrs
domain on the fields `event_id` & `event_ticket_id` in
the sale order line form (dialog). `event_type_id`
& `event_ok` are related to `product.product` fields,
in addition.
Changing the partner of the sale order triggers
the onchange on the lines, which triggers
the onchange of the `product_id`.
As these two fields `event_type_id` & `event_ok` were
not in the sale order lines tree view, as readonly,
they were passed to the write operation when
saving the SO, therefore writing on the product (the
same value than before, in addition).
Indeed, if an onchange returns values for fields
that are reandonly in the view, these are ignored
when saving/writing. However, if the onchange
returns values for fields that are not in the view,
these values are nevertheless passed to the write operation,
even if there was actually no change.
This behavior should probably change, that if an onchange
returns values for fields that are not in the view, these
are ignored, either when saving the record, either when
returning the result of the onchange.
Either way, these are risky changes, that we prefer to avoid
in a stable release such as 9.0. As a workaround,
we therefore add these fields in the sale order line tree view,
as readonly, so they are properly ignored when saving
the record.
This is important to avoid this write on `product.product`, as
users can have the write access to the `sale.order` without
having access to the `product.product`
(e.g. `Sales > See own leads` group)
opw-660716
When you are in form view and came from calendar, a screen refresh
throwed an error from fullcalendar lib. Also when going back to the
calendar view, it would not be loaded.
It is due to fullcalendar not being rendered if it is not visible, and
other part of the Odoo code are dependent on it having been rendered.
This commit hide the calendar after having been rendered.
closes#10253
opw-659314
The links present in forum messages are parsed to integrate "nofollow"
attribuate in it.
In case the content of the link contains some special char (e.g. <a>foo)bar</a>)
the regex fails as it interprates the content as an invalid expression.
The quantity is not correctly computed, and therefore the weight is
wrong.
The fix uses the appropriate _compute_qty method to convert the
quantity.
Closes#10204
opw-660801
Christophe Simonis