Odoo add the extra letter "s" to the translated word "Active User".
This is caused by adding "s" at the end of the word directly from the template,
which makes no sense in many language.
This prohibits translators from translating the plural form in any language.
The plural form and singular form of "Active User" should be translate
separately.
Fixes#12469Closes#12470
Use case:
-enable multi currency (use UDS as company currency and EUR as secondary currency)
-create account account in a different currency (EUR)
-create journal for the bank account in EUR
-create a new tax included tax
-create a new bank statement in EUR journal and add one line
-reconcile
-Choose a counterpart with the included tax and click on reconcile
Before the fix:
After reconciliation the amount_currency for tax and expense were wrong.
You could check this in the journal items linked to the bank statement.
Video:https://youtu.be/678rFb4OE2Q
opw:680693
When grouping result the BaseModel method _read_group_fill_results add
the possible groups which had no result.
But, if the order of the group is not consistent, we can get really
wrong results. The code logic is expecting that the grouped result
gotten and the list of groups (returned by _read_group_stage_ids of
crm.lead) is in the same order.
If the _order attribute of the model is not enough specific (as was the
case in crm.stage) the inconsistent order would kill aggregation values
(displaying 0 instead of what should have been present).
opw-680952
Before this revision, this was not possible to write
`statment_id` on multiple journal items at a time,
as the condition:
`if 'statement_id' in vals and self.payment_id:`
required `self` to contains only one record
On the cancelation of a bank statement line
reconciled with journal items created
by the registering a payment, in addition to unbind
the move with the statement line, the statement must be
unbind from the move, and the payment must be reset
to posted.
opw-680128
In v8, the field "Order Reference" was part of the "Import-Compatible
Export" fields. This is not the case anymore in v9 since the field is
always read-only.
The fix uses the same logic than v8: dedine the field as non-readonly
for state "Draft" in the model, but always set it to readonly in the
view.
opw-676095
In some cases, several barcode widgets can be found on the same page.
This is for example the case of the stock picking: there is a widget on
the `stock.picking` model (main view) itself, and a widget on the
`stock.pack.operation` model (modal view).
In this case, when the focus is not set directly on the field which
needs to be filled in, both widgets will trigger a `barcode_scanned`
scanned event. This will call the `on_barcode_scanned` Python method
which can lead to errors/warning. For example, the `on_barcode_scanned`
method on the `stock.picking` model raises a warning in case the barcode
scanned does not match any product/package.
The fix is to make sure that the event target is located in the correct
DOM element.
opw-677506
The field was removed from the form view at af9d21b3 during a refactoring but
was forgotten in the tree view.
It makes no sense to display a field that the user can not change.
The same field was already invisible on the product.product tree view since
43977de.
Make it invisible instead of removing it to avoid breaking potential xpaths.
Fixes#12418
This reverts commit a0eb172cab and thus
allow to actually use the longpolling feature.
The commit was made originally to better follow the debian packaging
guidelines.
A better solution will be implemented for v10: removing the `openerp-gevent`
script to replace it with a special argument in `odoo.py`.
There is still a dependency issue as we need psycogreen but this dependency
is not met in debian wheezy. This will be made a hard dependency for v10 as
it is available in debian jessie.
opw 678334
Cancelling a statement line should not remove the
according journal items if they are associated
to an `account.payment`.
In this case, this should simply remove
the `statement_id` of the move lines,
and unmark the `account.payment` as
reconciled.
opw-674896
[FIX] anonymization: default anonymization fields
res_partner.name was twice : remove one
res_users.name doesn't exist (now, it use the partner name) : remove
remove training.* fields that do not exists
Closes#11806
Actually, it was a Python ``Warning`` exception that was returned, and
not an ``openerp.exceptions.Warning``, that is an alias of ``openerp.exceptions.UserError``.
All actions of the database manager redirect the user after an action except the
backup option which returns an octet stream.
Close the modal after form submission to mimic the same behaviour.
Do not close the modal for other actions than database manager to avoid waiting
time for create that may be long to process.
Add message to warn the user about backup waiting time after cliking on submit
to be less confusing for big databases that may take a lot of time to be ready.
Fixes#10803
On an editable list view, an issue occurs with the following procedure:
- Click "Add an item", write something
- Press "Enter" key --> a new item is added, write something
- Click outside of the list, then click on the last item created
- Press "Enter" key --> the cursor is set at the beginning of the list
This is an issue for two reasons. First, the behavior is not the same if
we have clicked outside of the list before pressing "Enter", which is
not logical. Then, in some undetermined cases, the focus can be lost
then retrieved on the last record. It means that suddenly, the cursor
goes back at the beginning of the list without notice.
The latter issue is problematic when batch-encoding data, for example
encoding the lot numbers of incoming products thanks to a scanner.
opw-680758
The method `get_products_accounts` obviously requires
a fiscal position browse record for its `fiscal_pos` parameter:
```
@api.multi
def get_product_accounts(self, fiscal_pos=None):
accounts = self._get_product_accounts()
if not fiscal_pos:
fiscal_pos = self.env['account.fiscal.position']
return fiscal_pos.map_accounts(accounts)
```
But the method `product_id_change` called it with a fiscal
position id, through its own class method `_get_account`
This probably happened during the merge at revision
75d7bbb46e
which has not been correctly rebased on the acounting 9.0
revision
c04065abd8
opw-678735
* Fixes a bug that prevented the system to fetch the default provider
because the default_get call was wrong (wrong model + missing
company_id kwarg)
* Displays the amount as a monetary widget (to do that, the amount
must be sent as a float in the controller)
* Display the acquirer 'pre_msg' field to display eventual fees
When no `partner_id` was passed to `render()` and the acquirer
had a fees computation method, (e.g. Paypal), it would crash.
Could happen when coming through the /website_payment/pay
controller, for instance.
When the report `account.report_invoice` was being deleted,
it was no longer possible to reset an invoice to draft.
This is related to revision
291561a197
When tracking a page with special characters
in the title (e.g. `Ä`), the title
of the page in the tracked links was
badly encoded, because the
encoding was not handled correctly
when parsing the given website page.
opw-679993
In a batch reconciliation of journal items,
it could happen that multiple journal items
in a foreign currency required the creation
of an exchange entry
`aml_to_balance_currency |= aml`
But the statement `aml.matched_debit_ids[0] or aml.matched_credit_ids[0]`
requires a single browse record (singleton) to work
The partial reconciliation is supposed to be the same for all
the journal items to fix, we can therefore safely do
`aml = aml_to_balance_currency[0]` to overcome this issue.
In addition, in this condition, the full reconcile must be
skipped to avoid passing multiple times in the `create_exchange_rate_entry`
method (which is called in the method `create` of `account.partial.reconcile`
This has been reviewed by qdp.
opw-680044
res_partner.name was twice : remove one
res_users.name doesn't exist (now, it use the partner name) : remove
remove training.* fields that do not exists
Closes#11806
When a chart of account is created, ir.values for the fields taxes_id
and supplier_taxes_id in the model 'product.template' are created.
But if one of this two taxes are deleted, there was a crash when
creating a new product template because the default tax was missing.
opw:680576
When clicking on "Your Pipeline" in Sale app and clicking afterwards
on an opportunity, the form view "crm.crm_case_form_view_oppor".
But if you refreshed, the form view of a lead was used.
opw:677962
Khwunchai J