When there is a language and its base language translation files in a
module, in 12.0 an empty translation in the language translation file
will not fallback on the base language.
eg.
fr.po : {'one': 'un', 'seventy': 'soixante-dix'}
fr_BE.po: {'one': '', 'seventy': 'septante'}
=> the translation in fr_BE will be {'one': '', 'seventy': 'septante'}
but before 7288b477 it would have been {'one': 'un', 'seventy': 'septante'}
With this commit, an empty translation is no longer created so does not
override base language.
Also the intention of d84b795b0a that was also lost is restored by
upserting only noupdate==false translation, and inserting the other
ones.
opw-1904638
closes#28297
Since the opt out per mailing list, the intermediate model was used
to list all the recipient of a mailing list. The side effect was that
importing new contacts into mailing list was not possible anymore.
Also, creation of a new contact into a mailing list was made indirectly
by creating a new many2many record between contaxct and list, which was
not really user friendly.
This commit restores the mailing contact model as the view of the mailing
list recipients. In other terms, the contact import is restored.
An opt-out computed field as been added to be able to filter on opted out
contact inside the mailing list recipients view.
This opt_out field SHOULD NOT be used in a form view as it need the active
mailing list id in the context in order to be computable and searchable.
This field has no sense without this active mailing list id context.
Task ID 1891228
Linked with blacklist and opt out per mailing task (ID 33224)
Closes PR #27632
On mobile (specifically in landscape orientation as the height of the
viewport is narrower), the content appear over the bottom toolbar
instead of going below.
Solution is in 2 parts:
* raise the toolbar way above the content
* make the toolbar opaque
closesodoo/odoo#28429
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28408
Before commit 60f143c8e7, the dashboard
parameters did not use the parameters from the action, so some important
information could be lost.
However, in this same commit, the action context overrides the context
from the user defined views, which means that some information is lost.
For example, customized group bys are ignored.
This commit fixes the issue with some careful context manipulation.
Some special care was done to remove the groupby from the action context
if it is not empty, because that same logic is used in views.
Introduced by: 3d46887d38
Before this commit, creating an invoice from a SO always chose
the payment_method=all when the number of invoice linked to the SO >0
OR all the lines of the SO were with invoice_policy = 'order'
After this commit, creating an invoice from a SO just choose the payment_method=all
when the number of not canceled invoice linked to the SO > 0 AND when there are at
least one downpayment in the SO
SO:
Steps to reproduce the changement of behavior:
- Create a SO for 10 units (invoicing policy based on ordered quantities)
- Create the invoice for 10 units (from SO) and validate it
- Change ordered quantities to 5 units
- Click on create invoice on the SO
The payment method chosen was delivery instead of all. So choosing the default option
lead to a user error saying: there are no invoicable line instead of creating a credit note.
opw:1904258
closesodoo/odoo#28426
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
As empty arrays are considered truthy, the call to `/web_unsplash/get_app_id`
would always be performed even if no Unsplash images.
closesodoo/odoo#28421
Before this commit:
Reserved column appeared with 0 qty when Delivery Order goes to done Stage
After this commit:
Hide Reserved column when Delivery Order goes to done stage.
This task is related to #1888361Closes: #27223closesodoo/odoo#28409
Creating a service and stockable that create a PO on SO confirmation
(with different suppliers) will indeed work, but the status button
will only display 1 PO. The problem is that stock is not linking
the SO line with the PO line.
Thus, we prefer desactivated the button displaying the wrong value, as
it brings confusion to the user.
A proper bugfix should be done in master, to correctly link SO line with
PO line making the PO count correct.
opw-1905189
closesodoo/odoo#28410
Before 762adedece the search was done on the related field product_id
This was equivalent to make a search on the records order_line.product_id
and to use the name_search of product to find it.
With the filter order_line.product_id.name, it was explicitly searching on the
name of the template
Fixesodoo/odoo#28344closesodoo/odoo#28390
- Activate multi-currency
- Create an Journal Entry manually
- Create a line
Do not fill Account
Fill in Amount Currency
Fill in Currency
A traceback occurs because `line.company_currency_id`.
An extra condition `and line.company_currency_id` is not sufficient to
have the onchange working properly. Indeed, the related field
`company_currency_id` goes through another related field (`company_id`),
leading to an empty value in some cases.
opw-1904854
closesodoo/odoo#28389
When a record inaccessible by the user is linked
to a message in a channel accessible to the user,
Avoid to raise an access error due to this linked record.
Also need an aditional query in test query_count.
closesodoo/odoo#28312
The percentage field is computed in _compute_percentage as a value
between 0 and 1. This is good because that's what widget="percentage"
in views expects.
This makes read_group also return a value between 0 and 1, instead of
0 and 100. Otherwise list views will show e.g. 5000% when grouping
lines that sum to 50%.
Introduced in saas-11.4 at odoo/odoo@9148960174.
*Do not forward port, already ported to 12.0 via
odoo/enterprise#2975 (odoo/enterprise@a1484e650c)*
opw-1904481
On res.config.settings for website, when removing a language from language_ids, if this language is defined as default_lang_id, the default language will be updated by an onchange to prevent any inconsistency.
The same should happen when doing this directly on the form view of a website record.
closesodoo/odoo#27727
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
When sending notifications by batch one notification email can be send
up to 50 people. For one mail_mail entry to handle 50 emails can be sent
as those are sent independently for each recipient.
In some cases a bounce may occur while the whole batch of recipients is
not completely mailed. In that case the mailgateway will update the
notification status to bounced. When the cron finishes to send the whole
batch of emails it tries to update the notifications of all recipients.
However as a notification has already been updated due to the bounce we
face a concurrent update, meaning the transaction is rollbacked.
Emails have been sent but notifications are not considered as sent as they
have not been updated accordingly. Next time the cron runs it will send the
same batch again, with probably the same bounce and rollback. We could
therefore face an email loop.
This commit add test for this use case.
This commit is linked to task ID 1893054.
For unknown [1] reason, phantomjs starts to segfault when running qunit
tests.
Be radical with simply not using phantomjs anymore.
[1] Any guidance on tracking the root cause may help...
Seems like something similar to odoo/odoo#17111 can happen on Python 2.
The same change as #17111 is a bit involved for -stable, but this looks
pretty harmless.
Probably fixes#23781.
Nicolas Lempereur