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>
When importing vendor credit note from an italian e-invoice xml file with a "DettaglioPagamento" section,
the data import will fail and you will have the "Unsupported image format" message on top of the invoice.
The use of '_compose_info_message' function is not possible on a 'account.edi.format' object and was
changed to use the 'invoice' parameter.
opw-2500569
closesodoo/odoo#72018
X-original-commit: 8e886704a4efb9ca2f8d2e2b021f66d668af40d8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently, while reloading following success page
it return "Method not Allowed".
* submit track proposal and reload
* register for an event and reload
this commit fix this error and successfully
reload the page.
closesodoo/odoo#70087
Task-id: 2500573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The accounting date must be today by default and changing the bill date
must not affect that.
Kind of followup after this change of behavior fcaa54939e9a4f0dd5e47cd0ccffe7aa24bd451c
task-2550985
closesodoo/odoo#71977
X-original-commit: c63af09774414a004ef34644b4f38b4fdb1d12bd
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In `_remove_tax_used_only_by_self`, as tags will be properly
removed in `_delete_tags_from_taxes`, we should only remove
them from the `self.tag_ids` set without unlinking them
(unlink them at this step, might lead to issues if these tags
are still linked to `account.move.line` for example).
As stated in https://github.com/odoo/odoo/blob/7444857b631e4c26ac1f13e6c29dfaa6b4c66359/odoo/models.py#L3549-L3555
we use the command `3` instead of `2` to achieve this.
upg-61375
closesodoo/odoo#71969
X-original-commit: 6a85debb540bf9281b10f8a95be1ff0b4491eabc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This commit updates owl to the latest release. It only contains a
fix to better handle t-calls in nested t-slots
Release on github: https://github.com/odoo/owl/releases/tag/v1.3.1closesodoo/odoo#71989
X-original-commit: 5c66f47e849144f79ecf9dd63d51529be3510aff
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Suppose a POS with setting 'Advanced Cash Control' enabled. The user
starts/closes a POS session (no sale, no cash difference). In
Accounting > Cash, a bank statement exists, has no line and its starting
balance is equal to its ending balance.
The user has then to add a zero line, post an validate the bank
statement.
In such situation, the bank statement should be automatically deleted
when closing the session
OPW-2507394
closesodoo/odoo#71987
X-original-commit: 760c1b19229e2971ada911cd5607ceaea36e982f
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The mb-0 class has been added to the h4 tag of the progress bar so that
there is not too much padding if it is changed to simple text.
task-2542318
Part of https://github.com/odoo/odoo/pull/71426
Some changes in the delivery slip layout:
- For delivered products, replaces the Quantity column by two other
columns: Ordered and Delivered;
- Shows the non-delivered products even when the delivery is done and
haven't any backorder.
task-2373833
closesodoo/odoo#61366
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, on the delivery slip, the quantities aren't
displayed at the same way if we display the move ones or move line ones.
In the first case, we print directly the value from a record, so the
float decimal is correclty placed when the float is converted into a
string.
In the second case, we get the value from a dict, so there is no
conversion and the float is simply translated into a string.
For example, for 2 qty.:
- For a move it display 2.00
- For a move line it display 2
task-2373833
Open Accounting>Reporting>Invoices
Add measure 'Average Price'
The reported amount will be wrong, as it will not consider the quantity,
making an average of the price subtotal
opw-2522621
closesodoo/odoo#71862
X-original-commit: 978012b38abb941c88fe85f1befa2ac659545915
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
A security has been added to avoid an infinite loop due to custom
code if the failing orderpoints were not correctly return in order
to exclude them from the set to retry.
However after a first batch if some orderpoints were correctly exclude
orderpoints_exceptions will not be empty and during the second iteration
failed_orderpoints will be always filled from exceptions of previous
iterations and the infinite loop will not be detected.
opw-2525893
closesodoo/odoo#71938
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Antoine Vandevenne (anv)