Node content of inherited views using <attribute> tags are added
in the translation terms when syncing the terms.
The fact that the content should be translated or not depends
on the content, or to which attribute it refers.
For instance, string attributes should be translated, but
domains probably not.
But, even for domains, this is possible that it requires a translation
e.g. [('category_id.name', 'ilike', 'Customers')].
This domain is very unlikely to be integrated in the standard source code,
but this is possible to have such a domain in a view customization.
Therefore, we provide the possibility to disable the translation
case by case. Setting translation="off" in the attribute of the node
will prevent to add the node content in the translated terms.
opw-625762
Traceback because id was not casted: AccessError: ('AccessError', u"Database fetch misses ids (u'1') and has extra ids (1), may be caused by a type incoherence in a previous request")
default_get method of mail.wizard.invite model uses
the key 'default_res_id' to retrieve the res_id of the record
to add the followers.
In the case of recurrent events, virtual ids are used, and
the conversion from virtual ids to real ids is needed.
Pass the context, with the language setting, when the record is read to
fill the google drive template. That allows to translate the name of the
document and all the informations inside.
opw-626675
This rev. reverts partially 1d76586a1b
This rev. is related to #3462
Regarding addons/web/controllers/main.py
---
name of model ir.actions.actions is not translated
it's the name of server actions, client actions and window actions
that are translated.
Meaning the name of the ir.actions.actions will always be in English,
even when passing the user language within the context.
Regarding addons/web/static/src/js/views.js
---
There is no reason to pass the field values within the context
of the /web/action/load call: The read methods of actions are
not overidden to use the field values. Besides, it pollutes
the context of the action, leading to unwanted behavior, such
as the translation of the action name within the lang available in the
fields of the form view (e.g. the partner form).
Initially, the field values added in the context has been added
within the rev. 542928adde
Indeed, sidebar_context (or sidebar_eval_context nowadays), contains
the field values, and the additional_context passed to /web/action/load
is an extension of this sidebar_context.
We are not sure the reasons why the sidebar_context was passed to the
/web/action/load, but we believe it was to pass the session/user context
containing the lang, timezone, and so on, not to pass the fields values.
The headers array contains 2 sub-arrays, whatever the number of
measures. The test on nbr_measures was thus incorrect and produced an
error when downloading a table with a single measure.
Also fix the typo in dow(n)load_table function name.
The delivery module overrode the method _create_invoice_from_picking
to add the shipping costs according to the invoice and the shipping.
The issue is that the method _create_invoice_from_picking creates an empty
invoice, without any line. The lines are added afterwards, using the method
_create_invoice_line_from_vals, within the method _invoice_create_line.
So, after having called _create_invoice_from_picking, the invoice is indeed
created, but without lines, and therefore without the amount total value.
Adding the shipping costs there will thus prevent the shipping costs
based on the total price of the invoice (e.g. free for an order of 500€)
This rev. overrides the method _invoice_create_line instead, as, after
the call to this method, the invoice will be completely set, with all
its lines, and with a correct amount total. The side effect
is that we need to recompute the taxes a second time, using button_compute.
This is not the cleanest way to solve this issue. Indeed, a cleaner patch
would be to change the method _create_invoice_from_picking so it creates
the invoice along with its invoice lines, using the ORM command
(0, _, values) to creates the lines directly within the invoice creation:
invoice['invoice_line'] = [(0, _, values) for values in invoice_lines_vals].
Nevertheless, this is a bigger change, that will probably require API changes,
and therefore should be done in master.
opw-626226
opw-628517
Column `name` is required in ir.actions, and thus
automatically required in subclasses such as `ir.actions.act_window`
and `ir.actions.act_url`, due to the specific PostgreSQL inheritance
mechanism. Mark it so in the model to make it explicit.
This does not change the database constraints, as they should already
be set though inheritance.
Closes#4861
Many trivial changes to journal items, such as the
"blocked" flag for litigation (follow-up), do not affect
the balance of the whole entry. These should not cause
the account.move to be (re)validated.
For example it should be possible to change trivial
fields even on journal entries recorded in a closed
fiscal period.
The toggle button for the setup code in code examples of the webservice
page was mistakenly inserted between the setup code and the "actual"
code in the DOM. Trying to select the whole snippet (including setup)
would thus also select the text of the button and copy it to the
clipboard, breaking the copied code and confusing users.
Fix DOM order so selecting setup and actual code does not include the
text of the toggle button.
Setting an expense with a tax included with a negative base code sign was
getting the wrong amount (tax line as a credit instead of debit). So leading to
a total for the accounting entry superior of the total of the expense (should
not happend as the tax is included).
Add test to verify this scenario.
Fixes#4260, opw 618531
When overriding a field defined as a function field, the field must either
create a corresponding column that is not a fields.function (if stored), or
have no corresponding column (if not stored).
clicking on sales button, add a search + a default on the partner_id of the
opportunity, to directly filter and create quotations linked to the correct
partner.
The quick creation and account record opening in the sheets are not useful.
Besides, restricted users (simple employees) have no read access on account.account.
opw:626989
Christophe Simonis