When using a many2one widget, in the following scenario:
<h2><span t-field="o.partner_id.parent_id.country_id"/></h2>
If 'parent_id' is an empty recordset, the following error will be
raised:
[...]
[read] = record.read([field_name])
ValueError: need more than 0 values to unpack
This is because record.read([field_name]) returns an empty list which
cannot be unpacked.
In version 10 this problem is avoided by using recordset but to keep the diff
minmal in v9, only returns empty string as the line below does
`if not read[field_name]: return ''`
Closes#14489
The website `default_lang_id` was not required,
while the algorithm choosing the website language
expects it to be required.
This solves the below issue, when your browser language is en_US:
- add a second language to the website (e.g. fr_BE or es_VE),
- in the website settings, remove English from the languages
- in the website settings, unset the default language
- try to go on the website
You will have a crash:
```
File "/home/odoo/src/odoo/saas-11/addons/website/models/ir_http.py", line 193, in _dispatch
resp.set_cookie('website_lang', request.lang)
File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 992, in set_cookie
self.charset))
File "/usr/lib/python2.7/dist-packages/werkzeug/http.py", line 905, in dump_cookie
value = to_bytes(value, charset)
File "/usr/lib/python2.7/dist-packages/werkzeug/_compat.py", line 106, in to_bytes
raise TypeError('Expected bytes')
TypeError: Expected bytes
```
This is because the `request.lang` is set to `False`
because of the below algorithm in `ir_http.py`:
```
nearest_lang = not func and self.get_nearest_lang(path[1])
url_lang = nearest_lang and path[1]
preferred_lang = ((cook_lang if cook_lang in langs else False)
or self.get_nearest_lang(request.lang)
or request.website.default_lang_code)
is_a_bot = self.is_a_bot()
request.lang = request.context['lang'] = nearest_lang or preferred_lang
```
`nearest_lang` is `False`, because there is no nearest language
available for the browser lang (`en_US`)
`cook_lang` is `False` for users who never went on the website
`request.website.default_lang_code`, which is the last feedback,
is also `False` because you removed the default language
in the website settings.
opw-695621
The deleted code put the same picking_type_id for all companies.
The function _get_picking_in returns the right default picking_type_id
according to the company.
Steps to reproduce:
-stock.warehouse0 is on company A.
-Define another company B with its own warehouse.
-Update the purchase module -> a new default value for picking_type_id on purchase
order for company B is created wtih the value of company A
-Create a purchase order on company B, Odoo tries to get the picking_type_id from company A.
If user doesn't have any rights on company A, it occurs a security warning.
Otherwise the purchase order is linked to a picking operation of another company.
opw:694059
When passing a value along with a currency
to the `formatLang` method,
the currency symbol was added to the value,
but the amount wasn't rounded to the currency
decimal places, as it would be expected.
For instance, when using the currency "XOF",
with as symbol "CFA" and 0 decimal places,
2 digits after the comma were still displayed
in the accounting dashboard, while the user expects none.
This behavior to take the number of digits out of the currency
is already the behavior of the `formatLang` methdod in the reports
(`/openerp/report/report_sxw.py`)
it was just not yet the case in the misceleanous tools
(`/openerp/tools/misc.py`).
opw-695496
To reverse all the the exchange rate difference entries created during the reconciliation.
Before the fix:
Configuration
- Company Currency USD
- Multicurrency
- Other Currency EUR with exchange rates per day.
- Bank journal in EUR with allow cancelation.
Steps
- Create more than 1 invoice for customer in EUR and validate it. (Example. 3 invoices 100 EUR each)
- Create a bank statement in EUR Bank with the payment of that invoices (Example. 300 EUR)
- Conciliate the payment with the invoices.
- The journal entries for exchange difference are correctly created(three exchange rate difference entries).
- Cancel the payment from bank statement.
Bug:
There was only one reverse journal entry created for the exchange rate difference of the all reconciliation.
But three reverse journal entries for exchange rate difference entries were expected.
opw:694120
In `action_cancel` method below, the date_cancel is set when the linked invoice
is canceled.
When the canceled invoiced was reset to draft, the date_cancel was not removed.
This change makes sense as the state of the membership line is changed from
`cancel` to `waiting` when the invoice is reset to draft.
Closes#14313
When a user fills partially a date or datetime field, the system will
somehow autocomplete the value entered. For example, if the user enters
"11//11" then clicks on the Tab key, it will be completed as
"11/11/0000".
However, the year 0000 is not recognized in Python, and this causes a
crash upon saving.
opw-695035
Before this commit, amount updated from ajax request don't respect currency format.
Eg: 1.200,000 => 1200.00
Now we use the grouping/thousand separator/decimal separator from l10n,
and if class decimal_precision is defined in dom, we use it. (format=0.001)
This commits closes: #11553
This commits is related to #1103
valuation_price_unit must in the uom of the line.
Before the fix:
- Set "Use anglo-saxon accounting" True at company settings.
- Check that the "Account Properties" on product category are set (set a price difference account).
- Set costing method = Average price, Inventory valuation = Perpetual (automated).
- Create and confirm a PO (product purchased with unit of measure "Unit(s)" and purchase unit of measure "Dozen(s)")
- Validate shipment (Receive the product)
- Create and validate the supplier invoice
- View the accounting journal entries
Bug:
In the invoice journal entry, there were:
In the output account: debit=0.0 and credit=price unit of the PO line
In the price difference account: debit= (11/12)*price unit of the PO line and credit=0.0
In the input account: debit=(1/12)*price unit of the PO line and credit=0.0
Expected behavior:
In the output account: debit=0.0 and credit=price unit of the PO line
In the input account: debit=price unit of the PO line and credit=0.0
opw:694108
The employee form view button box should be enabled for employees,
it's up to each button in their respective modules to define
more restrictive groups, and in fact they already do
(see hr_holidays, hr_timesheet_sheet, hr_contract ...)
For example, hr_holidays adds the "Leaves left" smart button
which is supposed to be visible for employees looking at their own profile,
but it was actually hidden because they couldn't see the entire buttonbox.
Also added fixes to buttons that came afterwards and relied on this behavior.
fix for https://github.com/odoo/odoo/pull/14164
The commercial_partner_id field on "account.invoice" is a stored related
field to commercial_partner_id on res.partner and this field is recomputed
when changing the is_company field (by the function _commercial_partner_store_triggers).
So when changing the "is_company" field, the commercial_partner_id is recomputed and
a write is made on each account.invoice linked to the commercial_partner_id.
To avoid access rights problem on account.invoice, the write on "is_company"
must be done in SUPERUSER.
opw:694687
Backport of ab279d9cea
When getting the price from a account.move.line, the uom set
on the line must be taken into account.
Before the fix:
-Set anglo-saxon accounting
-Create two units of measure Box and Mot where 1Mot = 10Box
-Create a stockable product with Box as unit of reference and set with
real price and perpetual
-Create a SO with a Mot of this product
-Confirm the SO and create the invoice
-Validate the invoice
Bug:
In the journal of entries, only one box was counted for the debit and the credit
instead of 10.
NB: The function _get_anglo_saxon_price_unit must return the price unit of the
product in the unit of measure of the account.invoice.line.
opw:693075
When processing a partial reconciliation in a foreign currency, a
currency exchange difference might be generated during the
reconciliation process (see OPW for a detailed use case).
This prevents the user to process the reconciliation since he will get
the error: 'You have to provide an account for the write off/exchange
difference entry.'
The fix is to use the company-related foreign echange gain and loss
accounts automatically to book this difference.
opw-687975
When changing the company of a sales order,
the change was not propagated to the related, stored, company field
of its sale order lines
These triggers makes that happen.
opw-694683
When changing the company of a pricelist,
the change was not propagated to the related, stored, company fields
of the `product.pricelist.version` and the `product.pricelist.item`
These triggers makes that happen.
opw-694683
In some cases, when the destoy method of 'Tip' calls the off() function on
'$breathing', even if this one is not defined.
To fix this error, we check that '$breathing' is not 'undefined' before
calling off() on it.
When tax cash basis is used, the user might face the error "Wrong credit
or debit value in accounting entry !". A detailed use case can be found
in issue #14158.
The reason is that a float representation of `1.0` of the field
`matched_percentage` will become `1.000...2` when used in Python.
Therefore, such an expression such as `line.credit_cash_basis -
line.credit * matched_percentage` might lead to a slightly negative
value for the credit/debit, which will not pass the condition `CHECK
(credit+debit>=0)`.
Fixes#14158
opw-692797
Previous implementation did not allow the user to search for pages 'name'
but only on the slugified name.
Now we slugify the needles before to find a match.
1. Create a new page: 'The new'
2. add a link on your website and try to find this page...
- Before this commit, the only ways was to type 'the-new'
- After this commit 'the new', 'The new', 'The-new', ... will match
This commit closes#10771
Rev. 3f7d350fe21d9e2afb35a9ce3e2652940e3f259d1 introduced
auto-cancellation of the edit mode when the user clicks
outside the edited line.
The unfortunate downside was the auto-cancellation of the
edit mode also when the user presses ENTER while the
line is not valid.
This is especially annoying when using barcode scanners to
fill in values, as scanners usually send an ENTER keystroke
at the end of the input sequence.
When a many2one field is focused this event will often occur
before the autocompletion popup has a chance to open. At that
point the line is considered invalid, and the edition mode
is cancelled! If no field is considered dirty yet on the line
this simply drops the whole line, otherwise it will open a
navigation confirmation popup. Both results equally prevent
the use of barcode scanners.
This patch makes sure the edit mode is only cancelled when the
user indeed clicked outside the line, and not for other cases
where save() is requested, such as an ENTER keystroke.
The hw_scale module uses its own internal thread
for reading weights, independently of the polling
done by the POS screen.
The shortest internal reading interval is around
200ms, so polling every 50ms is useless.
150ms seems a good compromise in terms of perception
and resource use.
When we are trying to use the button 'set date to all order lines, we
get a traceback saying, that update cannot be done, because it ensure
that there's only one record. (After 9.0, there is no more this
'ensure_one').
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/401a3cfaf6fd09f594e45c181e908900acba3777
To fix it, we iterate over the order lines, and do the update of each
line.
This commits fixes the following scenario:
1. load the translations for any language
2. modify the source of a translated record (e.g. email template body)
3. click on 'load translations' button (flag)
4. execute the translation wizard for the same language (to refresh)
The translation of the modified record was duplicated.
This was due to the field src in the database being different than the msgid in
the po file. The src value is updated on the insert_missing call.
The matching on src for type='model' translations is only needed due to the
translations that are split (e.g. xml views or html content). For the other
translations, matching on the rec_id is enough.
Detects the xml_translate and html_translate fields to avoid matching on src for
these translations.
opw-691752
Closes#14310
-amount_currency in model account.analytic.line is a related field to move_id.amount_currency
where move_id is an account.move.line
-amount_currency is computed in function create on model account.move.line by considering that
amount = debit - credit (since 8.0)
-amount in model account.analytic.line is computed by considering that
amount = credit - debit (since 8.0) in the function _prepare_analytic_line.
So when creating a customer invoice with an analytic account in another currency, the created
analytic line has an amount which is the opposite of its currency_amount.
This commit also reverts the commit 7fca8ad89e to keep the same
behavior as in 8.0 for the creation of an analytic line from:
- an expense
- an invoice
- a task
The computed not stored field analytic_amount_currency displays the currency amount with the right sign.
opw:694085
Without this patch, when a product was added to cart, if this addon
was installed, it always landed in English in the SO.
This happened because the context, containing the current language,
was being aborted here (`context=None` instead of `context=context`).
This commit closes#14340
When a picking is partially available, and the company works in 'just in
time', they often need to re-check the availability of some products
just before sending them.
In 8.0, it was totally possible, to recheck the availabilty of products.
To fix this, we just add a button when the picking state is 'partially
availbale', which does exactly the same as 'Reserve', but is secondary
and contains the label 'Recheck availability'.
This reverts commit 897290dd3f.
It seems it breaks other use case, since this was fixing more a
usability thing (need to click back on code view to save code view
changes) it is better to revert than to add drawback.
A better fix should be introduced, or the solution would be to not fix
it and have a warning indicating what needs to be done.
opw-693052
Commit a572b8115c removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
Backport of rev: https://github.com/odoo/odoo/commit/2cf80e00752c68e443b0cd442ee50f7d6daaa455
opw-692873
Odoo Translation Bot