With the following view hierarchy:
A
|
B' (oe_structure_ID view)
Before this fix, when saving multiple templates at once from the same hierarchy
the COW views (website) would not be saved correctly as the first call to
`write` would COW the parent view, then the second concurent call to `write`
would create the child specific view under the generic parent view.
Instead, the generic parent should have been cloned to a specific parent view
and then the child view should be COW under the specific parent.
A A'
| |
B' B*' (This one is the old B', without B' changes in the html editor)
Instead of
A A'
|
B'
Calling the `write` one after another will do the trick. Indeed, when the
second call is fired, the first call has already triggered the COW behavior.
Thus, the second call correctly retrieves the COW view.
Another issue might still appear, if the parent view write is sent first.
Indeed, the parent view will be COW, thus the specific child view (second write
waiting to be fired) will be deleted to be added on the new specific hierarchy.
Thus, that write will then raise an error since the view does not exist anymore.
task-1934279
Fix#30447
Steps to reproduce the bug:
1. open an app such that there is a breadcrumb (e.g. an employee form view)
2. create a chat window with a user
3. click on the expand button to open the chat in Discuss
4. unsubscribe from the thread
5. click on the breadcrumb to go back
=> Traceback
When expanding the chat window to open Discuss, it registers a callback which
triggers an event on the mail bus. This callback is called when clicking
on the breadcrumb.
Because the channel was left, any related chat window is destroyed.
Since the widget is destroyed, it has no parent, so any service call
returns `undefined`, hence `getMailBus` returns `undefined`.
Fix: check if mailbus exists before triggering.
closesodoo/odoo#30640
Have a product of type service with :
- Service tracking : Create a task in a new project
- Project template : A project of the company
- Re-invoicing Policy : No
Create a SO with the product, and validate it.
Before this commit, when the project was generated. It was generated in
the company of the super user, and not in the company of the SO.
Now, the project is generated in the company of the SO.
OPW-1927005
closesodoo/odoo#30607
Create and write rights are granted on portal and user.
We need to improve the security.
task-1934286
task-1862656
opw-1862218
opw-1862111
opw-1857912
opw-1861426
Github-24986
forum-135070
closesodoo/odoo#25671
Fedora 29 switched to python 3.7. It seems that there is no official
way to build a RPM package that could works with 3.6 and 3.7.
Building two different packages for each version could open the pandora
box of packaging.
With this commit an ugly hack is used: if python3.7 is found, the odoo
directory is symlinked into its site-packages dir.
fixes#30579closesodoo/odoo#30618
Usecase to reproduce:
- Set 1 unit of product A in stock
- Scrap 1 dozen of product A
Warning message for Insufficient Quantity is not triggered.
It happens because there is no UoM conversion between scrap qty and
product quant quantity.
Fixes#30570closesodoo/odoo#30589
- Create a SO with 2 stockable products: 1 is available, the other is
not.
- Validate, go to the picking
- Set the 'Shipping Policy' to 'When all products are ready'
The 'Unreserve' button disappears, while some products were reserved.
When changing the shipping policy, the state of the picking is
recomputed and set as `confirmed` ('Waiting').
We make the button visible in this state also, when 'Shipping Policy'
is set to 'When all products are ready'.
opw-1932658
closesodoo/odoo#30635
In a pos session:
OFFLINE
make an order with invoicing , try to validate
The order stays there because it needs to be validated by the server
make another non invoiced order, validate
ONLINE
make another order
At validation, all orders will be pushed to the server
Before this commit, when trying to validate the invoiced order
the report download couldn't find the order id, and crashed
This was because the order in question was already pushed
but treated as a non invoiced order
After this commit, an "warning" message is displayed to the customer
saying he/she has to print the invoice from the backend.
In most cases it is enough and acceptable, since a customer would actually leave the premises
and come back later for the invoice
It is also safer in terms of data consistency to keep pushing all orders once the connection is back
OPW 1918044
closesodoo/odoo#30485
Before this commit, the web client had a naive strategy to handle lost
connections: it tried to poll the server every 2 seconds until a rpc
succeeds.
This works quite well from the perspective of the user, but may be a problem
from the perspective of the server. If a server is down for a longish period,
then each users active tabs will then perform a request every 2 seconds. This
means that the server will be progressively hammered by many requests, which
will clutter the logs, and make it more difficult to gracefully recover.
With this commit, we simply exponentially increase the delay each time, and add
a little jitter to give a better distribution.
Cherry-pick of 4a3f04bcc5closesodoo/odoo#30136closesodoo/odoo#30596
Have a tax that has a different account for refunds
make an invoice and its refund
Before this commit, the refund's tax is still in the old account
After this commit, the refund's tax is in the account for refund defined on the tax
OPW 1907950
closesodoo/odoo#30325
In case the discount product is misconfigured and therefore not loaded
by the POS, a traceback appears when applying a discount.
Add a comprehensive error message instead.
Closes#30574
opw-817527
closesodoo/odoo#30582
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes#30567
The sale.order model has an expense_policy selection field, with values in 'no',
'cost', 'sales_price'.
However that value can also be set to False.
The code that handles that field expected the value to always be set to a value.
We explicitly treat False as if it was 'no' (the default value for that field).
opw 1915508
closesodoo/odoo#30336
Commit f727e9d9b6 made the rating field
of mail.message non-stored for performance reasons.
When the rating is activated on the website, it adds the possibility to filter
product reviews by rating (1 to 5 stars).
It does so by searching the messages that have a given rating value.
However the osv complains that you can't search on a non-stored field.
As a result, instead of displaying messages filtered by ratings,
it would always display all of them.
We add a search='_search_rating_value' on the field to allow that field to be
searched anyway.
opw 1931038
closesodoo/odoo#30499
Before this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb do not preserve translation
warning.
After this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb preserves translation warning.
Technical note: alertFields is now an object and an attribute
of the form renderer
that stores translation alerts per record. The translation
alerts
created for a given record are maintained unless
they are closed manually or the renderer is destroyed.
Issue-ID: 1877480
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#29377
Instead of searching for the driver name and return thousands of partner
ids in the vehicule search, use a database join and a search on the
driver name.
closesodoo/odoo#29288
When thousands of invoices are in a different currency than their
corresponding journals, a large number of calls are performed to
`_get_conversion_rate`, and therefore `_select_companies_rates`.
Despite the fact that the query itself is optimized, the impact of
performances on the dashboard loading time is not negligible.
In order to avoid unnecessary queries, we create a cache dictionary to
store the rate values. This way, we avoid any unnecessary query.
opw-1920188
closesodoo/odoo#30552
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
closesodoo/odoo#30530
Use read_group is faster than the python equivalent,
and then don't push ids in ORM cache, which makes
the ORM faster later in the process.
Also unlink in batch.
For editing many2one fields (and partially many2many) most widget show
an autocompleting list of targeted records.
They thus have `autocomplete="off"` to prevent browser completion.
But chromium has an history of breaking `autocomplete="off"`, see:
- https://caniuse.com/#search=autocomplete
- https://crbug.com/468153
- https://crbug.com/587466
- https://crbug.com/914451
- https://crbug.com/923895
It seems that since chromium 71, the heuristic to ignore
`autocomplete="off"` has become more aggressive and for example if there
is at least 3 fields like an address in a page, chromium will ignore
`autocomplete="off"` for the fields like an address.
So for example the eidting the many2One field with placeholder "Country"
in a contact page now has a browser autocomplete menu that is:
- hidding the many2one autocomplete
- going to save empty country it appeared visually filled if the
autocomplete result was selected.
With this changeset, the placeholder in the many2one instance is
interspersed with U+FEFF charcters (ZERO WIDTH NO-BREAK SPACE) so the
browser does enable the autocomplete feature by force.
This should thus remove the issue (until it is fixed by chromium) in the
case of field named "Country" or matching other regexes in this file:
https://github.com/chromium/chromium/blob/cdb1b2073f12/components/autofill/core/common/autofill_regex_constants.cc
U+FEFF has been chosen instead of more recommended characters because
other have been shown erroneous for printing in some windows
configuration (see cb2a3afa7).
10.0 version of #30439
opw-1930588
closes#30439closes#30449
- Create a SO, do not set a partner
- Add a product with a tax
The untaxes amount as well as the taxes remain 0.0.
This is because there is no pricelist, therefore no currency.
There is actually no need of rounding explicitly since these are
monetary fields which will be rounded automatically.
opw-1931796
closesodoo/odoo#30450
OPW 1929160
A filter prevented from selecting a partner in the reconciliation widget if it had a parent company but a company with a parent company should be selectable
closesodoo/odoo#30270
`product_price_update_before_done` may be called with a `forced_qty`
argument in the case of unlock: unlock a picking, edit a received/sent
move and increase/decrease the quantities. In this case, the formula of
the AVCO was wrongly applied.
Closes#30513
opw-30513
closesodoo/odoo#30730
Cherry pick of 0edd3ea5b4 in version 12.0
Have a Lead with the contact informations (Customer Name, Street,
Street 2, City, State, ZIP, Country) completed in the 'Followup' page.
Before this commit, when the base_adress_city module was installed, the
informations of the City, State and ZIP where lost when we try to create
a new Partner from the Lead.
Now, the informations are present in the Partner form; furthermore if
the country allows enforce cities, the information is also present in
the enforce city form.
OPW-1932018
closes#30644closesodoo/odoo#30713
Commit 9af941428880af8e1810dfd9feef494d7a745e98
made it so that the value_from function depends on a variable defined after
the function complete has been called, without any guarantee that this function
would be called after. Apparently this is the right OOP thing to do.
opw 1930523
closesodoo/odoo#30712
Because Python only runs signal handlers on the main thread, native
calls (IO or accept(2)) can delay these handlers running. This is
especially problematic when one such call is completely stuck and
we're trying to dump the stack to diagnose the issue.
By running the actual worker's processing in a sub-thread and leaving
the main thread sleeping, worker processes should always be able to
handle signals.
closesodoo/odoo#30688
Task #1930691
Purpose
=======
If the download security is set to 'Authenticated users', the route should prevent public users
from downloading the slides.
closes#30281closesodoo/odoo#30399
Before this commit, the menu to go into the backend from the website was
not possible to open on iOS without opening the right menu first. This
was because position: fixed is not able to counter overflow: hidden in
iOS. This is the fix for stable versions, the proper solution will be
done in master.
Closes https://github.com/odoo/odoo/issues/29390
task-1923151
closesodoo/odoo#30507
- Debug mode,
- Add multi-company to admin (user id 2),
- Create new company (company 2)
- Activate res.partner multi-company record rule
- Create invoice
- with first company (the default one)
- with a customer having an email address that doesn't exist
- Send a message in the thread, making sure the customer is in the
follower
- Wait for the message to bounce (red mail icon in the thread on the
given message).
- Change user to company 2 (in the dropdown menu next to the user
dropdown menu in the upper right corner)
- Refresh, access error, even in the app switcher.
This is because Odoo tries to display in the notifications the email
that failed, and crashes because the user doesn't have access to the
partner of the email.
We filter out the notifications related to objects that the user doesn't
have access to.
opw-1924359
closesodoo/odoo#30348
Romain Derie