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>
Before we were unable to go back to the product screen when pressing back button after a reprint.
With this commit, we prevent the automatic setting of screen on the order.
This allow us to go back to the the screen relative to the current order we were.
closesodoo/odoo#71926
X-original-commit: 992913018df946d1f953e4e42c70aa1a0f4ae8cd
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Allows to send and receives invoices from the fatturaPA network via the webservice (SdiCoop).
- PEC mail is disabled when SdiCoop is disabled.
- Added account_edi_proxy_client, a registered user on the proxy (see l10n_it_edi_proxy on iap-apps), that features encryption. Generates a asymmetric keys, and keep the private_key to be able to decrypt file sent by the proxy (which it encrypted with the public key).
- Added a generic way to sign the requests made to the proxy.
TASK ID 2358882
closesodoo/odoo#71928
X-original-commit: 4c8afc413a8982b2e77712eab7cf7ddac9f3851f
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
In account_edi, errors are shown as html, and might come from an external service if they are returned by a web-service.
X-original-commit: 261c037a602edb907a4c2018cf8b0c8cab0f2f63
It is currently escaped as it is not Markup-ed and not considered safe.
It means raw content is currently displayed in sent emails, which is not
really what we expect.
closesodoo/odoo#71911
X-original-commit: 62e6bc216aefe93c4cd1cca8e39f124a8a298386
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
AFAIK, this documentation isn't built anywhere and is not maintained anyway.
Since the developer documentation was recently removed from odoo/odoo repository,
it's the right time to remove this old doc content.
closesodoo/odoo#71898
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When confirming a RfQ, even if a follower is subscribed to "RFQ
Confirmed", he will not receive any email.
To reproduce the error:
(Need a mail catcher)
1. Create a PO
2. Add a follower and edit his subscriptions:
- Check 'RFQ Confirmed'
3. Confirm the PO
Error: No mail has been sent. The user should have been subscribed to
"RFQ Approved" to receive an email.
OPW-2447234
closesodoo/odoo#71892
X-original-commit: b459fc86d895dcd0c4bab8bb8332241fe9a43a6f
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
