The function open_entries doesn't have to propagate the context
because it propagated group_by from other models.
Example:
- Click on Accounting > Adviser > Assets
- Click on Group by > Category
- Click on an asset
- Click Entries
The group by "category_id" was propagated on the model "account.move"
and it led to a traceback.
opw:692888
The widget html is used for plain text and html content.
Need to check if the content is a valid html code, if is not wrap with p tag every lines.
opw-692158
In a multi-currency environment, company currency is USD
- Create an invoice of 100 EUR, corresponding to 65 USD
- Register a payment directly from the invoice (button "Register
Payment") of 60 USD. Choose "Mark invoice as fully paid".
- The write-off line contains the amount in the invoice currency (field
`amount_currency` filled in.
This was introduced in commit 003f2ee9b.
On the other hand:
- Create an invoice of 100 EUR, corresponding to 65 USD
- Create a bank statement of 60 USD.
- Proceed to reconciliation, and create a write-off line of 5 USD.
- In this case, the write-off line does not contain the amount in the
invoice currency.
The user expects the same behavior in both cases, so we introduce the
amount currency in the second case.
opw-690784
Certain localities (eg. Colombia, but South America in general) legally
require somewhat complex behavior when validating a POS order.
It was difficult to implement this behavior in the POS. The
validate_order function did way too much and was way too large. If a
user wanted to add an additional check that an order has to pass before
allowing validation the user would probably have to copy all the
validate_order code.
To solve these issues we split the functionality of validate_order into
two functions:
order_is_valid: returns true or false depending on the validity of the
order
finalize_validation: finalizes the order by sending it to the backend
etc.
Fixes#13142Closes#13994
Up to this commit, the JS module system only notified failed modules as
an 'information' instead of an 'error'. This was annoying, since the
runbot takes the result into account, and might be green even though a
module failed to load.
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
Before, the quantities on the pack operations were set also for the
pack operations that should have lots and had not, which is an inconsistency.
As at the end of the PoS, errors are not shown and not rollbacked, this
created really nasty situations. With this code, it was never meant to
use lots in the PoS, but as the picking was not validated (but existed, because
not rollbacked) some people thought it as a wanted feature.
In the mean time, we had commit fafc048d02, but it will give
problems as it will not automatically create a backorder. It is
better not to do anything when lots are involved somewhere in the picking
as then the user will see the open pickings in the PoS Orders picking type.
It is also important to not do anything when it is a move without a picking.
Needs to be forward ported to saas-11, where the file structure changed.
opw: 692045
The tax has to be only on the second line because otherwise the accounting entry is not correct. Note that I'm not sure it is a usefull use case, but at least the accounting entry of the w/o is now logical and corresponds to what you expect (and what you see on screen). OPW 689806
Previous commit b6cbc36f9 hides volume, weight and standard price in the
product view if a product has variants. The use case was the following:
- Create a product (template)
- Give a value to these fields
- Add attributes to the product (this creates variants)
The values were reset to zero. This is a normal behavior since the
relevant values are now on the product (product).
This reverts commit b6cbc36f9a.
opw-692833
The POS attempts to auto-validate pickings and so it sets qty_done of
the pack operations to equal product_qty. In the case of a pack
operation about a tracked product this doesn't make much sense, as in
that case auto-validation will fail and serial/lot numbers have to be
manually specified by the user. Without this patch you end up with pack
operations that look like they're done, but still need to have
serial/lot numbers set.
opw-690516
This effectively reverts the patch 7bdd4de that was made on 8.0 then reverted by 001610e (in 8.0 too) but each of them manually forward ported to 9.0, except that the forward port of the last one forgot to remove the faulty commit.
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
Currently when using a language on the website, the following is done in
this order to choose which one will be used:
1) use a language code if present in the url (eg. /fr_BE/),
2) use a language similar to the one in the url,
3) use a previously choosed language (saved in cookie),
4) use the browser language if available on website,
5) use a language similar to the browser language,
6) use the default website language
When a bot is requesting a page, he could either not specify a browser
language (en_US is set as default) or sometimes specify english
erroneously.
In these instance, we will then never use the default website language
if an english language is installed.
This fix changes this behaviour so if a bot is visiting a page, the 4th
and 5th steps are skipped and the default website language is used
instead of using the browser language.
closes#14033
opw-690910
Steps to reproduce :
1. Create a new customer
2. Create an invoice with an amount of 50.- for this new customer and validate it
3. Create a refund with an amount of 70.- for the same customer and validate it
4. Create a Customer Payment for this customer and validate it. The Invoice will be paid with 50.- of the refund. 20.- are still on residual in the refund.
5. Create a new invoice with an amount of 50.- for the same customer.
6. Create a new Customer Payment for the same Customer and validate it.
The Full Reconcile Boolean stays checked inspite of "Open Balance" of Refund amount is less than the Invoice amount.
After the fix:
Full Reconciliation Boolean doesn't get checked and Allocation amount on invoice journal item line should be same
as Open balance of the Refund Journal Item. So Invoice stays open with Balance amount.
opw:691577
A field shared across registries is normally never setup from scratch, except
when its full setup cannot complete. This happens when a registry reuses that
field but fails to load, because the base and full setup of fields look like:
def setup_base(self, model, name):
if self.setup_full_done:
# optimization: keep base setup (1)
self.setup_full_done = False
else:
# do the base setup from scratch (2)
...
def setup_full(self, model):
if not self.setup_full_done:
# complete full setup (3)
self.setup_full_done = True
When the field is reused for the first time, its setup state `setup_full_done`
is reset to `False` (1), and it should be set to `True` again after completion
of full setup (3). However, because the full setup fails, the field remains
with `setup_full_done` equal to `False`.
In that situation, when the same field is reused again, it base setup will be
done from scratch (2), and therefore some attributes (like `column`) are reset
to their initial value. Because the full setup fails again, those attributes
are lost for other registries that share the field.
Fix this crap by precising the setup states: `None`, `'base'` and `'full'`.
When a field is reused, its setup state is reset to `'base'` instead of `None`,
and consequently it will never be setup from scratch again.
Depending on the version of dateutil, rule._bynweekday can either be
a tuple or a set (see https://github.com/dateutil/dateutil/pull/54), which,
in the case of a set, breaks the access by index (see related issue:
https://github.com/dateutil/dateutil/issues/24).
By casting it into a list, we make sure that we can access [0] in both case.
Credits to jke ; closes opw-690761.
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
Forward-port of 5d17749ff4 which has been
forgotten during previous forward-port.
When a group of tax is nested inside another group of taxes, the tax
amount and base are wrongly calculated. It is also the case when a tax
is applied after a group of taxes.
This is because the recursive call doesn't reuse the previously
calculated tax amounts and base, but always use the same entry amounts.
The fix introduces this behavior, and moreover makes sure to include the
tax group in the base amount only if it should.
Closes#13995
When clicking on "Show older messages" in the bottom of the chatter, the
page would jump to the top when the additional messages are loaded.
There is already a functionality in a discuss channel to stay at the
previous scrolling position (related to the content) :
https://github.com/odoo/odoo/blob/ffe0db0d/addons/mail/static/src/js/client_action.js#L506-L521
This fix does the same steps for the chatter.
opw-692010
Consider that you have a custom one2many field based on a custom many2one
field, and that you delete the many2one field. From that point on, it is
impossible to load the registry of the corresponding database. To prevent this
from happening, we add a check before modifying or deleting custom fields.
When unreconciling a payment from an invoice, the link between
the payment and the invoice (in many2many invoice_ids)was kept
and then the invoice still appeared when clicking on the button
invoices in the payment form view.
The invoice must be removed from invoice_ids.
opw:691692
When clicking on the trash to remove a line (e.g. a sale order line
in a quotation form view) while editing another line, it produces a
traceback (in most cases), or behaves randomly (less frequently)
like removing both lines, or one of them, or maybe none of them.
Anyway, this feature doesn't work at all, so this commit simply disables
it when we are in edition mode.
In a perfect world, we would fix the feature instead of disabling it,
but the code of the list editable is so instable that it would most
certainly break something else.
Closes#13778
The dashboard instantiates an action manager for each view it contains.
When removing a view from the dashboard, the $el of its action manager
is simply removed from the DOM, unbinding all DOM event handlers
attached on it and its children, but the action manager isn't destroyed.
It means that Odoo event handlers (like core.bus.on(...)) aren't unbound.
This causes a traceback when removing a calendar view from the dashboard,
because such an Odoo handler is defined, and tries to access some
autocomplete stuff that doesn't exist anymore since the element has been
removed.
This commit ensures to destroy the action_manager.
Closes#13858
- Invoice a POS order => the invoice number is for example 0001
- Close the POS session
- Invoice another POS order => the invoice number is 0003
This is because the journal used for the POS closing entries is the same
than the journal used for the customer invoices. Therefore, the closing
entry consumes a sequence number of the invoices.
This affects POS orders, but potentially SO as well if they use the same
journal.
This is fixed in v10 from commit b5b0d36b31. In v9, we use a workaround
by looking first if a `ir.config_parameter` named
`pos.closing.journal_id` exists. We use this journal for the session
closing.
opw-691771
We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.
This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.
Closes#13699Closes#13762
opw-690812
Before this patch, the debian package depends on `python-pybabel`.
According to the documentation, this is a dummy package for transition
from `python-pybabel` to `python-babel`[1].
This dummy package has thus been removed in debian stretch in favor of
`python-babel`, and the odoo package is thus not installable in debian
stretch.
To fix this, we depend directly on `python-babel`, which is available in
all debian releases[2].
Closes#13905
[1] https://packages.debian.org/jessie/python-pybabel
[2] https://packages.debian.org/jessie/python-babel
Nicolas Martinelli