- Create a calendar event
- Add invitees
The invitees receive a mail so they can accept/decline. When clicking,
the page is always displayed in the language of the administrator.
Since the `request` object is not directly associated to the attendee,
the template is not rendered in his language. Since (i) the template
should not be rendered lazily (see comment in code) and (ii)
`request.render()` does not allow the rendering in an arbitraty
language, we do a manual call to `render_template`.
opw-694718
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
1. Set up BoM component A with cost of $1 per kg
2. Create a BoM which uses 1t of component A
3. Execute the BOM Cost report
Cost of component A is $1, while it should be $1000.
opw-695014
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
The function _get_pl_partner_order must also return the available
pricelists on the website with promo code. In this way, the user
can use promo code on the website.
opw:694556
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
The decimal precision `Account` no longer exist.
This check is therefore pointless, and prevent
to change the rounding of the currency of the main company
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
Since revision 458aaca328,
the `groups` args of the method `_notification_recipients`
is a list of tuple, and no longer a dict.
The code here has not been adapted to this change.
It is now.
opw-695300
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
Rev. d6e1d41128 removed old API
compatibility layer, but failed to preserve the ability to
call certain public methods from the RPC layer, when extra
browse_record parameters were required.
In particular the @api.v7 version of
`prepare_move_lines_for_reconciliation_widget` was dropped
and there was no way to call it with a `target_currency` RPC
parameter anymore.
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
Call was done in ajax to speed up the moderation and don't wait refresh at each accpet/refuse post.
But the problem is that when you refuse a post, you need to be redirected to a new page to ask more
infos about the reason.
The fix is to do the request in ajax only when it is an 'accepted' post.
This commits fixes odoo/odoo@14462
When we enable in the settings 'Get 2 levels of approvals' with a
'Double validation amount', and then create a request for quotation.
When we confirm it, even if the total amount of the request for
quotation is below the amount set in the settings, the purchase order
needs to be approved.
We excpect that if a purchase order has a total amount below the
validation amount setting, the purchase order is automatically
confirmed.
So to fix it, we compare the amount when the user click on the button
confirm. And immediatly call the function 'button_approve' if the amount
is below the double validation amount set in settings.
Bug introduced in rev: https://github.com/odoo/odoo/commit/9d4efc81a
opw - 694381
Whitley