Backport following opw-1851612
[FIX] google_calendar: do not create an event with an invalid id
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
On an optimization done for not rendering each time the template, the possibility
of sending the template in the proper language when multiple recipients was lost.
This is being refactoring in master, but for this version, Odoo won't merge a
change in the behavior, although it's the correct one as in previous versions.
Extracted by pedrobaeza from https://gist.github.com/nim-odoo/8a9749037370343f05c7e6681324f576
(cherry picked from commit 386a936)
In some undertermined circumstances, a `KeyError` might appear in:
https://github.com/odoo/odoo/blob/f9737d79e77e9abf634c8eaa4b6ea331e2aa814d/odoo/models.py#L4898-L4904
Despite the lack of reproducible use case, it seems that this was
introduced from 59b010ac36. In the meantime, other
optimizations were introduced in the prefetching of related fields, and
it seems that the fix is not necessary anymore.
Running the same script than described in
https://github.com/odoo/odoo/issues/19536#issuecomment-333118947 , we
observe the following performances:
Before the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.306
On change with 20 lines (10 new, 10 existing) took 0.221
On change with 30 lines (10 new, 20 existing) took 0.208
On change with 40 lines (10 new, 30 existing) took 0.271
On change with 50 lines (10 new, 40 existing) took 0.306
On change with 60 lines (10 new, 50 existing) took 0.319
On change with 70 lines (10 new, 60 existing) took 0.354
On change with 80 lines (10 new, 70 existing) took 0.382
On change with 90 lines (10 new, 80 existing) took 0.506
On change with 100 lines (10 new, 90 existing) took 0.503
```
After the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.238
On change with 20 lines (10 new, 10 existing) took 0.259
On change with 30 lines (10 new, 20 existing) took 0.250
On change with 40 lines (10 new, 30 existing) took 0.233
On change with 50 lines (10 new, 40 existing) took 0.287
On change with 60 lines (10 new, 50 existing) took 0.325
On change with 70 lines (10 new, 60 existing) took 0.345
On change with 80 lines (10 new, 70 existing) took 0.451
On change with 90 lines (10 new, 80 existing) took 0.496
On change with 100 lines (10 new, 90 existing) took 0.423
```
The fix doesn't seem to be necessary anymore, so we go back to the
previous implementation of the computed field.
Closes#25448Fixes#19536
opw-1861468
- Store a token inside sessions to allow implicit session deactivation when needed.
backport of @da1f153d61d747d9357694382fe04f96c0ca886a @c8243e71c6da37547a19f61c58f25d5d03e13d38
- Activate the Sale option 'Tax-Included Prices'
- Create and print an invoice
=> the total is displayed on each line
- Activate the Sale option 'Sections on Sales Orders'
- Create and print an invoice
=> the total is NOT displayed on each line
The option 'Tax Display' only applies to SO, not to invoices. Moreover,
we make consistent the wording.
opw-1856623
In this commit, our hero backport c444b5a293 to 9.0
[FIX] google_account: fix google request exception management
Error thrown by google request is an urllib2.HTTPError that can be read
and loaded in JSON. However in some cases the result of the read may
be void or not JSON-ready. This was causing a crash in the error
management and hid the actual issue.
This commit tries to read and JSON-load the error but fall back on
simply displaying the raw error in case of issue when handling it.
opw-1851612
When returning None, the XML-RPC can trigger an error, making
the api unusable in certain cases.
So, we added return True and if the context is None we
use an empty dict, so if the context is returned in a dict,
it is not returning None either. Tests were adapted too.
Closes#22264
Before this commit, it was not possible to add an amount to a new
bank statement. The input (.o_form_field_monetary) appeared as disabled.
This bug was due to this commit: @a1224f5ca
This rule should be only applied to .o_form_field_radio.
Closes#18887
Task ID: 35832
Make sure to test `None` instead of any falsy value. Indeed, when we
want to explicitly pass a `False` default value, `set_multi` might
select an incorrect default value.
This is for example the case of `_inverse_product_pricelist`, where
`default_for_country` might be `False` on purpose.
opw-1858271
Before, when we created a picking manually with MTO+buy products,
put a scheduled date in the future and did "mark as todo", the
date on the po was related to now instead of that schedule date.
The scheduled date of the picking was passed to the date_expected
of the move, but not to the date of the move, which was passed to
the date_planned of the created procurement. By passing the
date_expected instead of the date of the stock_move to the
date_planned of the procurement, the po will have dates in function
of the scheduled date of the picking.
Courtesy of chienandalu. Closes#25223
Have a printer in a pos.config that doesn't have a url set
Open the pos
Before this commit, there was a JS traceback, since we tried to call
string operation on undefined.
After this commit, we avoid the traceback with a behavior that *looks like* the v9.0's
i.e. we don't care if the url actually means something, we put a message in the console though
OPW 1858063
closes#25442
Backport of 5f105d144d from v11.0
Commit 45c5a07d89 deals with displaying on the aged balance reports
the lines that zero out each other: an invoice and a payment of the same amount for the same partner
However, that commit overlooked that when there is a chain of reconciliation
that puts the report line to zero, it was displayed as well.
This present commit corrects this by making sure there are amls that detail the report lines
OPW 1857860
closes#25421
Steps to reproduce the bug:
- Set a language on your user
- Change the date format in this language and set '%d/%m/%y' (two digit year)
- Open the calendar and select day or week view
Bug:
- The date displayed on the column headings has 'y' where it should have the year.
To check the right date format: http://fullcalendar.io/docs1/utilities/formatDate/
opw:185924
The fact the pos config name get was doing
`config.session_ids[0].state`
led to the prefetch of fields of all the session_ids of this config
on reading `config_id` for the session form
Therefore, if a pos config had 1000 sessions,
it was prefetching fields of 1000 sessions when you actually
wanted only one session to display in the form.
Among others, the `picking_count` field which is
not stored and quite heavy to compute
In term of time, it went from 1 minute to 1 second
to open the form view of one pos session.
Backport of bc84eb2035 to 10.0
Countries with several official languages often have multiple names for their
states. Allow to translate the state name for such countries.
Some monolingual countries but, yet, with a need of translation of the addresses
such as China or Germany can add the same flag in their respective l10n_* module
Closes#25340
Usecase to reproduce:
- Enable multiple languages and companies
- Set one language on the admin and another on the demo user.
- Create a product and a translation for its name (both languages)
- Create an inventory adjustement in a company A for this product
- Switch on demo user (inventory manager rights but in company B only)
- Create another inventory adjustement for company B
- Add the invenory line with the product and save
The Inventory Line multi-company rule raise an access error
because the system set product_name on the inventory_line that is
a related field. Since it changes the product name with its translation
it will update it on other inventory line that have this product. The
other inventory line is in company A and the user don't have access to
it thus the access error is raise.
This adds readonly on the product_name since it should not be update
with an inventory line.
opw-1855137
Before this commit, if the user opened the LESS editor and emptied a
file, he may get a compilation error (as intended if the file contained
necessary variables and stuff) but this error also prevented to open
the editor again because some code tried to decode an empty content.
Now, when a file is emptied it is set to an unique line feed.
The code was actually alreadt made in this spirit, there was just as wrong call to the date_invoice field of the model instead of the local variable with the same name, which contained the right value.
Canceling the delivery order created for a "Make to order" product
cancels the related procurement.
But canceling the receipt order created for a "Buy" product" with reordering rule
didn't cancel the related procurement. In some cases, it can block the application
of the reordering rules.
Now the related procurement is canceled when the receipt order is canceled.
opw:1845345
The end time of a calendar event is constrained to never be before the start
of te event.
However when updating events, one path would first update the start of the event
before updating the end of the event.
So in case where (s_1, e_1) is updated by (s_2, e_2),
with respectively s_i < e_i,
if s2 > e1 then the update would violate the constraint and thus crash
the calendar update.
opw 1854394
Steps to reproduce the bug:
- Create a recurring meeting, with a start date with time (not all day) (for example 09:00),
a duration (for example 5 hours) , each week for example on fridays, for 3 occurences.
-Save
Bug:
- The start_datetime ("Starting at") was increased with the duration of the meeting.
PS: The displayed start and stop in calendar view were computed in function "calendar_id2real_id"
with the virtual id.
opw:1858154
Christophe Simonis