When creating the account translations using the account template translations
read it without the environment language.
Otherwise, when the translation is created, the content of `element.name` (the
source term to translate) might be in a different language and already
translated.
This was introduce during the migration at the new API where previous code did
not propagate the context (probably by accident).
Before this commit, the only way to translate a chart of account was to install
the language (if present in 'spoken_language' field on the chart of account
configuration) **before** the installation of the chart of account.
This commit loads the translations of the chart of account at the installation
of the language too.
To avoid recreating translations at each update of a language, skip if the
language is already installed.
This means than, to benefit from the fix, already deployed instances should
remove (after de-activating it) the language and reinstall it to translate
existing chart of account.
opw-670327
Closes#11091
When a specific SMTP server is set on a mail template, it is never used
when the mail is sent. There are two reasons:
- `mail_server_id` is a read-only field set by an onchange. However, a
read-only field is not sent to the server, so the information is lost.
- The information is stored in the context of the object `Mail`, but it
is never used. Moreover, when the method `message_post` is called, the
`Mail` object is not used to post the message, so the information is
lost again.
The fix includes two parts:
- the `mail_server_id` field is not read-only anymore. Actually, there
is no reason to make it read-only.
- the information is stored directly in the mail values and used at the
appropriate moment.
Fixes#6554 (from v9.0)
opw-669958
In Odoo 7.0 & 8.0, this was possible to translate
a field label, from `en_US` to `en_US`. It was
used as an easy way to change the fields label,
instead of creating an inherited view changing
the string attribute of the field everywhere it was needed.
This was no longer the case in 9.0,
following the revision 9593a29.
The translated terms for `en_US` have been
excluded, for performance reasons
as it was considered not possible to have
translated terms for the `en_US` language.
The fact is, this is very possible: Nothing
prevents to add a translated term
in `en_US` for a translate-able field,
as this is the case for the fields label,
as mentioned above. This field is then
used as the display value instead of the source
term when being in the `en_US` language.
Besides, the above revision was mainly to
give the possibility to sort a model records
on a translated field, using a join on the translations
table. It was then considered that the join could
be avoided, in the case where the user language was `en_US`,
for performance reasons, but, as this is possible
to give another value to the field value trough
the translations, it should actually be done, even
for the records sorting.
opw-670814
Test to bind save and discard buttons of an editable tree view are done
only once when initializing it.
But if the view is by default grouped at the beginning, it will be then
"not editable" but only removing the groupby will change this.
So this commit add a case so if the view is grouped when initialized,
the buttons are always bound.
closes#11198
opw-666794
In the POS we use a touchmove event listener to stop undesired
rubberbanding (in Chrome.disable_rubberbanding()). Elements which should
be scrollable by touch should have the touch-scrollable class. The
receipt screen is obviously one of those, because otherwise you won't be
able to scroll down if you have a long receipt.
opw-670899
When a bank account is set within another currency
than the company currency
(the currency of the journal is set and is different
than the company currency),
the balance displayed was the amount within the company
currency, instead of the amount within the bank account
currency (despite the fact the currency displayed
was the one of the journal).
opw-670815
Convert the domain to display only the sale / purchase
taxes in the taxes list to a default filter doing the same thing,
but which give the possibility to remove the filter
and see taxes with the scope `None`.
opw-670737
When printing a BOM structure using a variant,
the specifications of the variant were not
displayed in the BOM Structure lines,
making it different than what can be found
in the BOM structure form, and therefore
making it impossible to know which variant
has to be used for this BOM structure
from the report.
opw-670448
When printing the production order, the name
of the product did not include the variant
specifications, making it different then what
is displayed on the production order form,
and preventing to know which variant was produced
for this production order.
opw-670448
When the user converts the lead into an issue, an error occurs: "Form
view couldn't be loaded". This is because the web layer tries to refresh
the data related to a deleted record.
Instead of deleting the lead, we archive it.
opw-670259
When a lead/opportunity is created, the probability must match the
probability associated to the stage, as introduced in commit b2733391.
However, the call to `_get_default_stage_id` looses the context, which is
an issue since the method `stage_find` will inspect it in order to find
default values to build the search domain. The result is that the manual
call to `_get_default_stage_id` might return a different result than the
automatic call from `get_default`, and therefore the probability does not
match the stage
opw-669960
When the user click on save, 'is_valid' is called on each field.
The o2m test all sub-field (apply modifier and check value).
But, if a modifier change the read-only attribute, the field is reinitialized and call 'render_value' without check 'no_rerender' value.
The relational fields call the db in render_value, and the x2m is invalid because a request is pending.
(change X2ManyListView to keep the 'no_rerender' initial value)
opw-653120
Therefore, the template could be seen from
the Discuss module, when clicking on "Send Mail",
but, when attempting to use it, it failed
(as it was not applied on the right model).
opw-670546
When an analytic account is specified in the reconciliation, the
analytic lines are not created. This is because the account move is
posted before the account move lines are actually created.
Fixes#10951
opw-670110
In an environment where multiple database are available the company_logo
controller in the web module will return a placeholder logo (the Odoo
logo) if it can't figure out what db the request belongs to. This logo
is used on the ESC/POS receipts.
Because we load the logo with an anonymous CORS request there is no
authentication on the request. This is necessary because the POS tends
to not be served over HTTPS whereas the rest of Odoo is. Without this
crossOrigin attribute we could potentially end up in a situation where
the canvas is considered tainted by the browser which would prevent us
from extracting the canvas' data with toDataURL(). So removing the
crossOrigin attribute is not an option, specifying the db is the next
best thing.
opw-670471
note: in >=9.0 session is a variable defined in the js module instead of
a property on PosModel, so 'self.session.db' should become 'session.db'.
Moving a whole package (option "Allow moving packs") results in a
traceback. Indeed, the method `_get_all_products_quantities` returns
product ids, while `_create_extra_moves` expects browse records.
opw-668180
When counting the 'activities' on each opportunity/lead,
this view only considered messages with a subtype that
matched the subtype of a specific crm.activity.
This was not consistent with the crm.opportunity.report
which counted *all* messages on an opportunity as
"activitiy entries".
The latter is considered better because any entry,
(even automated one for tracking field value changes
or automated system responses) corresponds to an "action"
taken on that record.
This patch makes crm.activity.report consistent with
this decision: it will now count all messages.
+ also convert the incorrect `left join` to a plain
[inner] `join`, as we don't want deleted leads to
appear in case orphan messages were left around
(which should not happen anyway).
Using a subselect is more efficient than constructing
a complete temporary table of all messages, and then
joining them. This way only messages or relevant
opportunities are used, as most of the time the
report is accessed for a specific subset of opportunities
(by date, salesman, stage, etc.).
The query planner can then use the dedicated index
to quickly access the corresponding messages.
On a sample database with 1 million crm.lead
entries and 10 million mail.message entries
this brings the time for a typical read_group
call on crm.opportunity.report down from 300s to
500ms (600x faster)
Copy/paste mistake and the comma stays at the end of the line. This
causes a wrong affectation : indeed, `index_content` gets a tuple with
the desired value. This does not cause crashes, and the representation
of the tuple is correctly stored in database, but this is not the
expected behavior.
get_template should accept ids or xml ids. However the id or xml_id is given
to IrUiView.get_view_id that waits for an xml_id. get_template crashed if it
received an id.
This commit solves this by setting view_id to the given id, or resolve the xml_id
through get_view_id.
From issue 660592. (already fixed in v9) When products are received from a purchase line
with taxes included, the cost for the stock valuation (on the stock move) on reception
should be without these taxes included.
Checking url_list for duplicates is O(n).
Use url_set instead of url_list to improve to O(1).
Otherwise sitemap generation even for a million products will never finish.
Close#11106
This function is there to avoid creating link modules, it is extended
by account modules and should be called by methods that create invoices.
This call was missing in sale.
The function _set_additional_fields is used to avoid creating a ton
of auto-install modules; account extension extend this function and
modules that create invoices call it.
But when calling this function, it would be better not to overwrite
existing values; hence this check.
Christophe Matthieu
