Right now, for notifications handled by odoo (which are being displayed on
discuss app / object chatter), few of the buttons have unexpected scroll
(mostly the CTAs that redirect to record / portal views) and ruins the UI.
This commit fixes the issue by improving such templates by using proper
paddings on the button.
TaskId:2518863
closesodoo/odoo#70083
Related: odoo/enterprise#18225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Variable `mutations` may have thousands of records. Using `.push(...mutations)`
would lead to error
STEPS:
* install website_sale
* create many categories:
```
for x in range(0, 4000):
env['product.public.category'].create({'name': str(x), 'parent_id': 9})
```
* open /shop
* click [Edit]
BEFORE:
```
Uncaught RangeError: Maximum call stack size exceeded
```
---
opw-2515707
closesodoo/odoo#72169
X-original-commit: 853a2cab3f896e99d5a4c498eea6ebf02e787b94
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a view is created/modified, it is required to validate it, the
validation checks the syntax, the inheritances, the fields, etc. When a
view is rendered there are a few more steps to perform like to (dis)able
the `edit` button from a view form if the user only have `read`
accesses. Those postprocess are useless when the view is validated and
should only be performed when the view is rendered.
closesodoo/odoo#68469
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This is a pure technical fix, computing `view.xml_id` is only needed
when there is a problem with the view. Computing the `xml_id` is not
free, as it needs to be retrieved from the database. During a regular
installation, there should be no problem, the view is validated without
errors or warnings.
By default, whatever is written on field 'arch' is handled by its
inverse method inverse_arch(), which writes on the low-level field
'arch_db'. When writing on 'arch_db', the cache is cleared, which leads
to performance loss because the arch needs to be re-fetched.
This optimization bypasses the inverse method on view creation, this is
safe as there is nothing wrong in the cache and makes view creation 20%
faster, and installation 7% faster.
Also make this a configurable value, from the server.
This is the limit of the SAAS servers.
closesodoo/odoo#72143
X-original-commit: bcd1c8aade6123dd20d7aebaae8a0f204f258604
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before, only the url input was focused when initializing the link
tools.
Now, we also scroll to the bottom of the options so that the user
directly has access to them.
Part of https://github.com/odoo/odoo/pull/71909
task-2542318
closesodoo/odoo#72122
X-original-commit: 748418d95059ad7ed5638aa4e4aca76da30fa6b3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Computing the image quality in preview when the slider was moving was
problematic for large images on chrome and FF. The preview for this
option has been removed.
Part of https://github.com/odoo/odoo/pull/71909
task-2542318
X-original-commit: da79bb6b3216ee71fe283c394d4c8acb5f76cdab
A new parameter displayHandles was introduced on SnippetOptions to
display or not the handles on a snippet. If a snippet had no option
needing the handles overlay, the overlay (and handles) from its closest
parent with such option was.
Two use cases were not tackled correctly and should display overlay,
even with no option with displayHandles:
- root containers (which have no editable parent)
- inline snippets (movable snippets)
Part of https://github.com/odoo/odoo/pull/71909
task-2542318
X-original-commit: 4b7dd2dbd378a9dc465e3e3fd8e32806df66919a
Small fixup of recent commit 5800f20ccf63ef8482d1460f46c8c5fe30eac822.
It can happen that line_residual is equal to line_residual_after_reconciliation.
This should lead to a zero reconciled percentage instead of a ZeroDivisionError.
closesodoo/odoo#72064
X-original-commit: 9cc8ac4a86fff81af397c89fbbc197bec222622e
Signed-off-by: William André (wan) <wan@odoo.com>
On account analytic lines, employee_id can be null.
https://github.com/odoo/odoo/blob/c63af09774414a004ef34644b4f38b4fdb1d12bd/addons/hr_timesheet/models/hr_timesheet.py#L48
```
Traceback (most recent call last):
File "/tmp/tmpowipzc_d/migrations/base/tests/test_mock_crawl.py", line 155, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpowipzc_d/migrations/base/tests/test_mock_crawl.py", line 245, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpowipzc_d/migrations/base/tests/test_mock_crawl.py", line 335, in mock_view_kanban
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpowipzc_d/migrations/base/tests/test_mock_crawl.py", line 394, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4839, in search_read
result = records.read(fields)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3020, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3040, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5666, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1019, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4061, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/14.0/addons/sale_timesheet/models/project.py", line 90, in _compute_warning_employee_rate
dict_project_employee[line['project_id'][0]] += [line['employee_id'][0]]
TypeError: 'bool' object is not subscriptable
```
```
❯ psql test_14 -c '\d account_analytic_line' | grep employee_id
employee_id | integer | | |
"account_analytic_line_employee_id_fkey" FOREIGN KEY (employee_id) REFERENCES hr_employee(id) ON DELETE SET NULL
```
Observed on upgrade request 16289
opw-2525553
Steps to reproduce on runbot (or local db with -i sale_timesheet and
deoma data)
1. Select Project > Office Design
2. Change project settings:
Settings tab > Billable=True
Invoicing tab > Invoice Tasks to=A unique customer
> Pricing=Employee rate
3. Save
4. Delete Employees > Eli Lambert
5. Open Project main menu -> Traceback
closesodoo/odoo#72081
X-original-commit: 71c3897a07918679717d57f65eeadb34b54cdcbd
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If the driver is a follower of the vehicle he will still be notified on the
chatter activities
closesodoo/odoo#72072
X-original-commit: f5419a1860c94df95f663c64370b23a8943a4e68
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
On a product form, if the purchase UoM is different from the default
UoM, this will lead to an error when creating a RfQ.
To reproduce the error:
(Need stock)
1. In Settings, enable "Unit of Measures"
2. Create a product P:
- Cost: 100
- UoM: Units
- Purchase UoM: Dozens
3. Create a RfQ:
- Add P
Error: The quantity is 1 and UoM is Dozens, however the unit price is
$14400. The ratio has been applied twice.
When setting the product, an onchange method computes the unit price.
However, the computation is wrong: it first converts the product's
standard price using the purchase UoM of the product. Then, it converts
the result, this time using the UoM of the PO line.
OPW-2519294
closesodoo/odoo#72139
X-original-commit: b37a13d7763e4a69695fdb1567dce5d0f69ff78a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before commit 139dd9d, only validation transactions made with a validity
check (transfer of a small amount with immediate refund) led to the
creation of an `account.payment` record for the reconciliation. As that
amount was never perceived, there was in fact nothing to reconcile.
With commit 139dd9d, it is possible to make $0-validations (the validity
check is handled by the provider). As this feature now sheds light on
the flawed behavior described above, it has been decided to entirely
stop creating `account.payment` records for validation transactions.
This commit thus prevents the post-processing of validation transactions
from preparing their reconciliation.
task-2494916
closesodoo/odoo#72137
X-original-commit: f460d7a5a995cd7b934d32f82b50aede43efbace
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Steps:
- Go to Surveys
- Create an new survey:
- Questions:
1. First section
2. First question:
- Multiple choice: only one answer
- Answers:
1. First answer
- Choice: Yes
- Is a correct answer: Checked
- Score for this choice: 1
2. Second answer
- Choice: No
3. Second question:
- Multiple choice: only one answer
- Answers:
1. First answer
- Choice: Yes
- Is a correct answer: Checked
- Score for this choice: 1
2. Second answer
- Choice: No
- Options tab:
- Conditional display: Checked
- Triggering question: (First question)
- Triggering answer: (First question, First answer)
- Options tab:
- Layout: One page per section
- Scoring: Scoring with answers at the end
- Click Test
- Select the two correct answers
- Submit
Bug:
The score is 50% instead of 100%.
Explanation:
Since multiple questions are submitted at the same time, we cannot know
before saving the question whether the following is still going to be
active.
This commit re-evaluates, for each question, which are the ones that are
still active.
opw:2537713
closesodoo/odoo#72126
X-original-commit: ec836acdc7bf10212f14a8bc98eac4cfa2f12e26
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Before this commit, the alternatives products were not multi-website filtered
to the admin.
The suggested product were filtered by website thanks to the
`website_published` filter.
This only concern the admins, as for portal and public user, all of this is
done automatically by the ACLs anyway, where we force_domain to
`website_published` products, which also filter by website (see the mixin).
This will also eases module inheritance as we use `sale_product_domain()`.
Fixes#67501closesodoo/odoo#72044
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
We call the status of the hostapd in each request of 'get_odoo_server_url()' and 'get_ssid()'
And this call display in the log the status '0' or 'inactive' in the log
With this commit we hide this useless information
closesodoo/odoo#72133
X-original-commit: e5e9f9f91cf9bf35f1e0b307008840a0de134e2f
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The `mode` field in used in `_combine` to distinguish `primary` views
from `extension` ones. The field has been retrieved as part of the query
done in `_get_inheriting_views` and manually placed in the cache so the
ORM doesn't perform an extra query just to retrieve the mode.
Using our benchmark (render_all_views test tag, website_sale, mrp,
contacts, crm and timesheet installed), the reported time was 18.46s
with 17890 queries performed without this improvement, it is 17.82 with
17340 queries with.
Closes#72096closesodoo/odoo#72127
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This only impact admins, as public/portal users have `website_published` forced
to true automatically through the ACLs.
On shop, we don't hide unpublished products for the admin.
Before this commit, the alternatives products were not multi-website filtered
to the admin.
The suggested product were filtered by website thanks to the
`website_published` filter.
This only concern the admins, as for portal and public user, all of this is
done automatically by the ACLs anyway, where we force_domain to
`website_published` products, which also filter by website (see the mixin).
This will also eases module inheritance as we use `sale_product_domain()`.
Fixes#67501
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Improve _compute_sale_order_ids performances by saving
stock.move.line search results to defaultdict before going
through records in self.
closesodoo/odoo#72019
X-original-commit: d908351fbaec8900244a82ec3a2d678e279535cb
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Currently, adding a padding to media is done with a select, which gives
a limited amount of options based on bootstrap classes.
This opens up the play field for the user by letting them input their
own pixel value.
closesodoo/odoo#72112
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
To reproduce the error:
1. In the settings of a POS, enable "Header & Footer"
2. Add this footer: "0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
5"
4. Start a session
5. Validate an order
- Note that in the footer, there is a line break after the third '3'
6. Print Receipt
- Error: the line break is after the third '5'
7. Send the receipt by email
- Error: in the receipt of the mail, the line break is after the
third '2'
The appearance should be the same in the three cases. On step 5, here
are the values used to display the receipt:
https://github.com/odoo/odoo/blob/6c1172922505cd955d278bc80d327423fc6867a6/addons/point_of_sale/static/src/css/pos.css#L1680-L1692
This fix applies the same ratio `width/font-size = 18.75` on values used
to print the receipt (`266 / 18.75 = +-14`) and the ones used to
generate the receipt in the mail (`512 / 18.75 = +-27`). That way, the
appearance of the receipts remains similar.
OPW-2528558
closesodoo/odoo#72085
X-original-commit: 26c74a1d19e838b5f7af4f3d2c9c79afc07deb27
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
To reproduce the error:
1. In the settings of a POS, enable "Header & Footer"
2. Add a header (with at least one line break)
4. Start a session
4. Validate an order
Error: The header of the receipt is incorrect, line breaks are not
applied
OPW-2528558
X-original-commit: 66c695b23c81c864c273314570b200a00a01641d
Issue
-----
When a lead with an automated probability is merged with other leads and
if its probability is 0, it will be considered as null value and will be
erased by the value of the next lead with a probability > 0
The final lead gets a probability != automated_probability and is now
considered is_automated_probability = False. Therefore automated probability
computation will not be triggered anymore.
Expected behavior
-----------------
Possible use cases
* if the probability is auto on the master keep the auto probability;
* if the probability is manual on the master keep that manual value even if
it is 0 as sales people know their pipe and gave an accurate probability;
In other words: never take the probability from the merged records and always
keep the master one.
Task-2526926
PR odoo#70270
X-Original-Commit: odoo/odoo@4e14997f92closesodoo/odoo#70270closesodoo/odoo#72073
X-original-commit: 8fa6c154b196ec5bebb37293e70f9009a56e7974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, leads without any team_id set had their automated
proabbility computed based on the subset of all leads without team id.
Unless wrongly configured or strange pipeline use, all leads end up with
a team_id set. Therefore subset of leads without team is not really a
good set used to estimate probability of new leads.
After this commit, a lead with no team_id set yet will have its
automated probability computed based on the entire lead set.
Task-2526926
PR odoo/odoo#70270
X-original-commit: be1a55b305057803a67ec2b016e51325c992586f
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault François <tfr@odoo.com>
`NameManager`'s validation passes should not be language-dependent.
Fetching translated model and view information thus incurs additional
costs for no reason. Ensure translations are never enabled for
`NameManager`'s work.
In our benchmarch (py-spy with a rate of 200, render_all_view test-tag
and website_sale,mrp,contacts,crm,timesheet installated), 20% of the time
was spent in `NameManager.__init__` and thanks to this change it is
reduced to 11%. Queries count from 19995 to 17886. Total runtime from 24s
to 21.5s.
closesodoo/odoo#71419
Task: 2463632
Related: odoo/enterprise#18596
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
The post-processing of a view was implemented as a recursion, the
processing of every XML node recursively processing its children nodes.
Recursion inside flamegraphs scatters sub-calls at many call depths,
which makes their analysis less obvious. Transforming the recursion
into a loop with a stack makes the code more profiler-friendly.
Task: 2463632
The parsing of the values of attributes `attrs`, `states`, `invisible`,
`readonly` and `required` is done many times during the post-processing
of a view. The functions `ast.literal_eval` and `safe_eval`, although
being pretty cheap, are called so many times that they represent about
10% of the time spent in `field_view_get()`.
The variables of the function were poorly named, we take this commit
opportunity to rename them: `a` => `attr`, `v` => `value`.
After analysis of what was evaluated, it turned out that 95% of the
expressions safe-evaluated were '1', '0', 'True' and 'False'. We
introduced the special cases to quickly bypass the evaluation and speed
up the rendering.
Using our benchmark (render_all_view test-tag with website_sale, mrp,
contacts, crm and timesheet installed) the runtimes are 27.58s without
this commit and 27.45s with.
Task: 2495504
The view methods `get_inheriting_views_arch`, `apply_view_inheritance`,
`_apply_view_inheritance` and (previously `read_combined`)
`_get_combined_arch` were complicated and not optimal performance-wise.
The previous approach to retrieve views and combine them was to perform
it recursively, one primary view at a time. This new approach retrieves
in a single SQL query the whole tree of views to combine. The order of
view combination has been reproduced to be fully backward-compatible.
We also introduced various optimisations such as pre-fetching and
caching.
**get_inheriting_view_arch**
The method have been renamed `get_inheriting_views` as it returns a
recordset of views instead of the xml architecture of each view.
During an upgrade, only the views that have been fully upgrade already
are safe to be used. The views returned by the query are filtered to
remove any not-upgrade-yet view. Because this part is highly specific,
it has been isolated in a dedicated private method.
View extensions can be discarded according to user groups. The
retrieval of groups on views is also made by the same query. This
reduces the number of SQL queries, and makes the filtering faster.
**apply_view_inheritance**, **apply_view_inheritance**
The functions were responsible to build a hierarchy of views and to
iterate it to combine the views.
The hierarchy building have been moved to `_get_combined_view` and the
actual combination have been moved to a new method `_combine` and
documented.
Task: 2541579
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The method read_combined() has been deprecated in favor of explicit
calls to read() and get_combined_arch().
There are places where we call _get_combined_arch() instead, in order to
avoid parsing the XML that has just been serialized. This saves useless
serialization-deserialization.
Task: 2541577
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Extract architecture combination out of `read_combined` to work on
`etree.Element` exclusively: since `read_combined` returns a serialized
`arch`, its own recursive calls as well as callers needing to
post-process the architecture have to re-parse the `arch` then serialize
it back.
This is wasteful and can be avoided by providing the `arch` as an
`Element`, which is what `_get_combined_arch` does.
The public method `get_combined_arch` is provided as convenience: it
basically wraps a call to `_get_combined_arch` and returns the result as
a string.
Task: 2541577
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
A test that calls fields_view_get() on all models while measuring its
performances. Use it along with py-spy and load the generated file in
<https://www.speedscope.app/>
py-spy record -F -r 200 --format speedscope -o speedscope.json -- \
python3 odoo-bin -d <db> --test-tags render_all_views --stop-after-init
Task: 2463632
Co-authored-by: Raphaël Collet <rco@odoo.com>
When demo data is installed, requests to the proxy are blocked and we simulate a successful result by default and the proxy.
- an account_edi_proxy_client.user is created even though it's counterpart on the proxy doesn't exist.
- sending invoices is successfull and checking the status return simulate the invoice was accepted.
- the cron checking for incoming invoice returns immediatly and no new invoice is created.
closesodoo/odoo#72092
X-original-commit: 7be2e136c5e7a62d440f8323f36076d486976825
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When registering a payment on an expense, we are currently using the first
bank account set on the partner if no account is set on the account move.
We should use the bank account defined on the employee instead, and
fallback on the partner only if it is not set.
closesodoo/odoo#72077
X-original-commit: e0335a71afbeb34c5fad9a71bd1b53d5d88d6fa6
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
In case we register one payment on a single accounting entry, we can manually
specify the bank account that will be used. In case we register one global payment
for several entries, the bank account is not visible in the payment register wizard.
We should use the first bank account set on the partner as a default case to allow
it and not block the whole process.
closesodoo/odoo#72080
X-original-commit: 23560f70592fa3ae481d0ba7617cfeae243b7594
Related: odoo/enterprise#18968
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Those field are all handled by the account.tax.report.line creating the tax tag. They should never manually be changed by the user.
OPW 2541071
closesodoo/odoo#72049
X-original-commit: 44c32bf9c7b00655398c019371e4a128a6fac413
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Prior to this commit:
- If a user without access to sales tries to add timesheets on a task that
comes from a sale order, the following access error is raised:
Access Error
You are not allowed to access 'Sales Order Line' (sale.order.line) records.
After this commit:
- A user without access to sales will be able to add timesheets to a task that
comes from a sale order without any error.
task-2566750
opw-2525342
closesodoo/odoo#72025
X-original-commit: 9437bd543a40c3fc59979f70683be1acd7c995e7
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>
Munaf Khan