- When installing an accounting l10n module, the method `try_loading_for_current_company`
is called and could cause a deadlock.
The deadlock is caused by the fact that if the installation is started
via a web request the code tries to retrieve the current user's
company by doing `request.env.user.company_id`.
This causes issues since the installation code has its own postgresql
cursor while calling `request.env.user.company_id` will create its own
cursor.
So two cursors exists for the same Odoo worker.
The installation cursor asks for a lock on `res_users` while the
second cursor (the request one) will try to read on `res_users` and
wait the first lock to be dropped.
The lock is never dropped since the python code isn't running anymore
waiting for the `request.env.user.company_id` to be completed.
Causing the deadlock.
To fix the issue, we avoid the creation/usage of a cursor created by
`requesŧ`.
So to retrieve the current user's company, we read the user id on the
request's session, then browse the `res.user` record with the
installation cusror.
Fix issue introduced by commit d40956c790closesodoo/odoo#29927
The tests of the sale module are not constistent. Success depends on version
in use (com vs ent) and the modules installed (sale, stock, event_sale).
**Fix 1**
The "Description" field is updated by a onchange while saving the record.
**Fix 2**
The `sale_stock` module adds a new step to click "ok" on the warning modal
shown when saling a product without enough of that product on hand. The added
step was added to test_01 (that doesn't show the modal) instead of test_02.
**Fix 3**
There is a difference between the price of the SO between community and
enterprise.
**Fix 4**
The event_sale module changes the form view thus need to perform more steps
to create a record.
opw-1912266
closesodoo/odoo#29679
When running in kiosk mode, it is necessary to refresh the interface
once a week since the session is garbage collected.
The garbage collection method `session_gc` relies on the last
modification time of the session file. However, the session file is only
saved when the field key `should_save` of the session request is `True`.
This happens when the session is `modified`, i.e. an item on the cookie
is set.
In practice, the session is saved at each reload of the page. Regular
RPC calls, such as the one used in commit 6e1b660f9c, do not
trigger a modification of the session file. Therefore, we create a new
route which explicitly sets the session as `modified`, which ultimately
triggers a `save` in `get_response`.
opw-1917254
closesodoo/odoo#29919
Before this commit, the notification "Odoobot has a request" would
stay on screen even though the user blocked them in Firefox.
This case occurred when the user clicks on "Not Now", which tells the
browser that the push notifications should be blocked until the next
page reload.
This commit fixes this issue, so that the notification is removed
when clicking on "Not Now", in addition to cleaning tests related
to push notifications.
Task-ID 1918476
closesodoo/odoo#29584
Imagine the following use case: you have a partner (company) with
children (person). Selling a service to that company will create
a task on SO confirmation. Then the project lives its life, and
sometime a person of that company requests a task. The task
customer is the person, but should be linked to the SO as the
time spent on its should be invoiced to the client (the company,
customer of the SO).
This is not possible, as the selectable Sale lines for a task was
the one of the exact partner of the the task.
This commit changes that by checking the commercial partner instead
of the partner. So, for reporting purpose, we can keep the real
customer of the task, and correctly invoice the related timesheet
on the SO of customer company.
opw-1915703
closesodoo/odoo#29921
Create a Sale Order linked to a timesheet, for k hours.
Add the a line for the k hours, invoice the SO.
Then, next time you add a line or modify the value of an existing line,
the SO invoice_status becomes "upselling".
Then, everytime you do it again, it triggers a recompute which writes the
invoice_status "upselling" on the SO.
Now since commit 17c9b7afee every time you write
an invoice_status as "upselling" this creates a new activity to upsell the SO.
However it was intended to run only once, the first time the status changes.
Before creating an activity, we check what was the invoice_status to ignore
records that were already in that state.
opw 1911642
opw 1919283
opw 1919284
closesodoo/odoo#29891
Sending a letter resulted systematically in an error due to the insertion of the binary of the PDF in the JSON sent to IAP-services.
closesodoo/odoo#29880
The original issue is described in #29528, and the commit was reverted
in eb19016ba3.
The root cause of the issue was that the module `base.automation`
performs a `commit()` in `_update_registry`, which is called during a
`create`. This conflicts with the `savepoint` created in `load_demo`.
We postpone the registry reload after installing the demo data. Note
that we only do this in `base_automation`, to limit the potential side
effects.
opw-1920636
Co-authored-by: Raphael Collet <rco@odoo.com>
closesodoo/odoo#29863
This revision moves the `cache_key` to the first level
dict of the cache, instead of the last one.
Doing so, we reduce the number of times the reference
to the cache key is stored in the dict.
For instance,
for 100.000 records, 20 fields and 2 env (e.g. with and without sudo)
formerly, there were 100.000 * 20 * 2 occurences of cache key references
now, there is only 2 references.
Storing references to an object consumes memory.
Therefore, by reducing the number of object references
in the cache, we reduce the memory consumed by the cache.
Also, we reduce the time to access a value in the cache
as the cache size is smaller.
The time and memory consumption are therefore improved,
while keeping the advantages of revision
d7190a3fd0
which was about sharing the cache of fields
which do not depends on the context, but
only on the cursor and user id.
This revision relies on the fact there are less different references
to the cache key then references to fields/records.
Indeed, this is more likely to have 100.000 different records stored
in the cache rather than 100.000 different environments.
Here is the Python proof of concept that was used
to make the conclusion that setting the cache_key
in the first level dict of the cache is more efficient.
```Python
import os
import psutil
import time
from collections import defaultdict
cr = object()
uid = 1
fields = [object() for i in range(20)]
number_items = 500000
p = psutil.Process(os.getpid())
m = p.memory_info().rss
s = time.time()
cache_key = (cr, uid)
cache = defaultdict(lambda: defaultdict(dict))
for field in fields:
for i in range(number_items):
cache[field][i][cache_key] = 5.0
# cache[cache_key][field][i] = 5.0
print('Memory: %s' % (p.memory_info().rss - m,))
print('Time: %s' % (time.time() - s,))
```
- Using `cache[field][i][cache_key]`:
- Time: 3.17s
- Memory: 3138MB
- Using `cache[cache_key][field][i]`:
- Time: 1.43s
- Memory: 756MB
Even worse, when the cache key tuple is instantiated inside the loop,
for the former cache structure (e.g. `cache[field][i][(cr, uid)]`),
the time goes from 3.17s to 25.63s and the memory from 3138MB to 3773MB
Here is the same proof of concept, but using the Odoo API and Cache:
```Python
import os
import psutil
import time
from odoo.api import Cache
model = env['res.users']
records = [model.new() for i in range(100000)]
p = psutil.Process(os.getpid())
m = p.memory_info().rss
s = time.time()
cache = Cache()
char_fields = [field for field in model._fields.values() if field.type == 'char']
for field in char_fields:
for record in records:
cache.set(record, field, 'test')
print('Memory: %s' % (p.memory_info().rss - m,))
print('Time: %s' % (time.time() - s,))
```
- Before (`cache[field][record_id][cache_key]` and cache_key tuple instantiated in the loop):
- Time: 4.12s
- Memory: 810MB
- After (`cache[cache_key][field][record_id]` and cache_key tuple stored in the env and re-used):
- Time: 1.63s
- Memory: 125MB
This can be played in an Odoo shell, for instance
by storing it in `/tmp/test.py`, and then
piping it to the Odoo shell:
`cat /tmp/test.py | ./odoo-bin shell -d 12.0`
closesodoo/odoo#29676
* = account, sale_management, website
Settings that are using groups internally should not appear on the user form
without using debug mode.
The admin should not get the idea that he should configure those per user,
because they are going to be reset if/when changing the general setting.
closes#29842
PR: #29860
The generated query in _generate_goals_from_challenge lacked spaces
between the date clause, which caused a traceback.
The traceback only appears since v12 and above, because the dates are
now casted as dates (::date) in SQL, which has to be followed by a
space. Before that it was "fine" as SQL does allow you to write
g.start_date = '10-10-2017'and g.end_date = '11-11-2017'
Closes#28773closesodoo/odoo#29836
Some aria attributes were missing on menus, and are required to ensure a
good compatibility with keyboard users and screen readers.
To solve the above, the following attributes are included:
- `aria-expanded`: this should be present in all dropdown menus. This is
set on elements with class `dropdown-toggle` and `o_closed_menu`.
- `role`: used to improve given information about what elements are for.
It is added in the following cases:
1. Non-button elements that have the class `dropdown-menu` are set to
`role="button"`.
2. Menu items that have the class `dropdown-item` are set to
`role="menuitem"`.
3. Menu separators that have the class `dropdown-divider` are set to
`role="separator"`.
This is a continuation of baa1c515c5closesodoo/odoo#29719
Suppose calling get_fiscal_year(date, day=29, month=2) with date(year=2017, month=2, day=28)
The computation steps are:
date_from = date(year=2017, month=2, day=28) - 1 year = date(year=2016, month=2, day=28)
date_from = date_from + 1 day = date(year=2016, month=2, day=29)
It's incorrect because the value of date_from must be date(year=2016, month=3, day=1)
closesodoo/odoo#29416
The week_start has been added as an option since commit 27b30daea5.
This stores as a database parameter the day starting the week, [1.. 7] starting
on Monday, while the calendar options expect to get Sunday as 7 % 7 = 0.
As a result the week number would be shifted.
Commit c72403d2ba solved the issue,
this commit adds tests for it.
opw 1916666
closesodoo/odoo#29838
The field ignored is set in javascript on company object to filter the
ones we want to show. As it is not an odoo field, it triggers a
traceback when the trigger_up 'field_changed' is called.
OPW-1921568
closesodoo/odoo#29864
The fields `validity_start` and `validity_stop` are `Date` fields, they
should therefore be compared to `datetime.date`.
opw-1918843
closesodoo/odoo#29834
When using:
```
t-field="res_company.logo" t-options="{'widget': 'image'}"
```
the widget generates a `/web/content/` URL, which ultimately checks the
access rights in method `binary_content`. This means that if the user
doesn't have the `read` access rights on `res_company`, the logo won't
be displayed.
We use the `/logo.png` route instead since it bypasses the access
rights.
opw-1913665
After making improvement to allow user to choose first day of week per
language, it was not taken into account that calendar view uses
different weekdays indexing than newly added field `week_start`. The
difference is in Sunday, where in calendar view it has index 0, but
week_start index is 7 (other days' indexes match).
opw 1916666
closesodoo/odoo#29471
Without this fix, the test does not work at the start of the year, because it is
reliant on a date that is hard-coded on the currency rate demo.
Instead of changing the demo, this commit will make the test stronger by not
depending on it.
PR: #29850
opw-1916935
Before this commit, when a next activity was closed, the message said
that the action was performed by the assigned person.
Now, the message say that the action was performed by the person who
closed the activity.
closesodoo/odoo#29678
Purpose
=======
When changing the leave type on a leave request, reset the technical
fields that only have a visual purpose to avoid mismatch on the leave
duration compute method.
closesodoo/odoo#29789
1/ self.date_from on a for loop on self won't work
2/ When calling get_work_hours_count with self.date_from=False or self.date_to=False,
this will lead to a traceback when looking the timezone on the date.
Closes#29697
We wanted to make it possible to manually mark records from the partner_autocomplete service as 'ignored' so that they wouldn't appear in suggestions.
Previously, this was done by removing, in the service, records that were marked as 'ignored' from returned suggestions.
The problem is that, since the record was not present in odooSuggestions, the data from this company was retrieved from clearbitSuggestions and the company was still present in the dropdown.
We fix this problem by also returning ignored companies from the service, marked as 'ignored', so that they can be filtered out after getting additional suggestions from clearbit.
closesodoo/odoo#29785
The information of the active model and record was not given in the context
Records created from the Manage Messages and Manage Attachements in the debug
menu were not linked to the current records
Add context in test too
closesodoo/odoo#27766
Before this commit, there was a slight chance that the "add to wishlist" button
would flicker `disabled` off, which caused the tour to go next step too early.
The flicker was because the `_onChangeVariant` could be triggered by the
`website_sale` code before the variable `this.wishlistProductIDs` was actually
set, so it wrongly computed the state and enabled the button.
Now the RPC is done on the `willStart` instead of `start` to solve this issue.
The tour has been edited to check the button is actually disabled initially.
The view has been edited because the existing condition was too lazy: it checked
if any variant of the current template was in the wishlist, instead of checking
for the variant actually displayed. That also caused a flicker when the JS
correctly computed the state for the variant afterwards.
The widget has also been edited to trigger `input.product_id` instead of
`input.js_variant_change:checked` to avoid calling `get_combination_info` twice
from `website_sale` code.
PR: #29675
task-1920036
This step was meant to be "check" but did "click" instead because no empty
function was provided.
This caused a nondeterministic issues where an unwanted RPC generated a warning.
Indeed by clicking "add to cart" when checking if the button is disabled, that
called `create_product_variant` on non-dynamic product.
PR: #29675
task-1920036
Some features are common to portal and backend, such as the sign modal in
enterprise.
This commit uniformize the width of the modal to make it more consistent between
the two by default. Of course themes can still customize this behavior.
closesodoo/odoo#29521
The commit a35df8d371 changes the odoo object
of "rules" from stock.location.path to stock.rule. The field on the first
object to store the destination location was location_dest_id but is location_id
in the second one.
This commit fix the variable name that refers to the destination location
opw : 1919655
closesodoo/odoo#29755
Pingen validates the format of documents before sending them. These are the elements that it checks and how when ensure that the constrains are validated:
- The recipient's address should appear in a predefined area
--> Move the address to this area and reduce the font-size if the address is too long
- The destination country should be the last line of the address
--> Sometimes, the Tax ID was in this zone, so we add a margin after the address
- Above the Address Area, there should be a Postage Area that should be completely empty
--> Make the background white to avoid having a background image in this area
--> Crop the header if it takes too much space
- There are margins of 5mm all around the document
--> Crop the footer 5mm above the bottom of the page if it takes too much space
- There is a square in the bottom left of the document that should be empty
--> Add a margin on the left of the footer
closesodoo/odoo#29522
In `test_enable` mode, `render_qweb_pdf` fallbacked to `render_qweb_html`. We add a context key to be able to force the rendering of the pdf, even in `test-enable` mode.
The "customer invoice" and "vendor bill" string was untranslated.
Instead of adding a _ call, properly translate it.
No need to try saving bytes by splitting the sentences, this makes it very
difficult to translate in some languages where the order of words are not the
same as English
closesodoo/odoo#29690
Nans Lefebvre