When reading customized views from our dashbord in reporting,
the measures selected in the customized views were not taken into
account. It happened when the customized view was build from a report.
opw:698105
When syncrhonizing an allday event while being in a negative timezone
e.g. Dec 22 in US/Eastner (-5:00)
The event was synchronized the day before
e.g. Dec 21
because `context_timestamp` of `start date-time-` was used,
and then the time was removed to have the date of the all day event
e.g. 2016-12-22 00:00:00 converted to 2016-12-21 19:00:00 and then the time
removed 2016-12-21.
Instead of using the `start_datetime`, we now use the start
date which stores only the date, without timezone information
(and this is what you would like in the case of an all day event).
opw-697202
While choosing a start/stop datetime in a timezone hour
were the UTC value is within the next day,
e.g.
Start time Dec 22 20:00 in US/Eastner (UTC -5:00)
Therefore, start time Dec 23 01:00 in UTC
Checking the "all day" box made the start time set to
Dec 23 instead of what the user expected, Dec 22.
This is because the onchange simply took the UTC datetime
(Dec 23 01:00) from which it removed the time (Dec 23).
This revision make sure to remove the time from the
user timezoned datetime instead, so the day set
remain the same day than what was set in the datetime.
opw-702065
Event with interval > 1 was not correctly computed.
This patch doesn't fix existing event but only the new one created after this fix.
Event 1/1/2015 repeat every 3 months, 6 times
Before this commit : end recurrency = 1/1/2015 + 6 * 1 month
After this commit: end recurrency = 1/1/2015 + 6 * 1 month * 3 (interval)
This commit closes#14332
Fix datetime where the return of rrule is sometime a list,
sometime a set according to the datetime version.
list(set) == list(list) and works in both cases.
Similar fix: #9f09c62
Do these steps:
1. Create a partner.
2. Grant him portal access through *Actions > Portal Access Management*.
3. Delete the created user.
4. Delete the partner.
You will get this error:
```
Odoo Warning - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: Portal User Config - portal.wizard.user]
```
This happens because the wizard (which is a transient model) does not let the partner to be deleted.
With this patch, we avoid that bug.
Closes#12608
As the number of holidays are float, we may get a flloating point error when
comparing and having -0.0000000001 instead of 0 for the number of remaining
leaves, making the test fail.
Closes#12809Fixes#14643
The requirement for somebody to choose a ticket product should be that it is an
event, not that it has an event type attached, mostly when `event_type_id` is
not a required field.
The event has been improved in upper version but as this field is only
informative, relaxing a bit the domain.
Closes#12475
When sending an email via the mail.compose wizard, the selected partners are
stored in the context (`active_ids`).
If the composed message is saved (button "save template"), the context is lost
in the _reopen action.
The active_ids content of the new context is the id of the newly created mail
template and is used as the id of a res.partner (sending the email to a
different contact).
Keep the context during the reopen to avoid losing active_ids.
Closes#11947
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
Declaring the keyword argument `context` in an API v7 `orm.browse_record` can
lead to mixed API v7/v8 inheritance bugs (`context` will be treated as a
function parameter instead of being injected in `self.env.context`). As the
context is already propagated in line 953, we can safely remove it from line
971.
Closes#13115
When the user name entered hasn't an email specified the error message wasn't
displayed in the reset view.
The error message was in e.name, not e.message
Due to the following revision:
456d7b38f1
The company on the order line was not assigned
when creating a new line in an existing sale order.
The company was correctly assigned when you created
the order line with the order, and when changing the company
of the order, but not when adding a new line on an existing order.
This new trigger repairs this regression.
Due to the following revision:
295b96c0b3
The company on the version and items was not assigned
when creating a new pricelist version on an existing
pricelist.
They were if you changed the company of the pricelist,
thanks to the triggers added in the above revision,
but not when they have just been created in the pricelist.
These new triggers repairs this regression. It also handle
changing the `pricelist_id` of a version (this is doable through
the "Sales > Configuration > Pricelists > Pricelist Versions" menu).
Fixes#14631
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
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