Steps to reproduce:
- create-aprove-post an expense
- Go to the accounting dashboard
Issue:
expenses' amount is 0
Cause:
In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result:
https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644
Solution:
Get the right columns.
We also change the domain to make sure that expenses partially paid are also displayed.
Note:
For the test we check that even partially paid expenses are displayed. In Master we want the residual amount to be displayed.
In master:
Use the amount_residual (discussed with po Laura)
opw-3849036
closesodoo/odoo#162182
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Usecase to reproduce:
- Create a MO for 2 unit (1 component per finished product)
- Produce 3 units
- Mark as done
- Unlock and change the quantity to 3 units
Expected behavior:
3 components removed from stock
Current behavior:
6 components removed from stock
It happens because the set_quantity_done create a new stock.move.line
with excessive quantity. Then the write of qty_producing in
mrp.production will write this quantity on all the `stock.move.line`.
It results by moving number of sml * the new quantity producing
Solution do the write of new quantity done on the `stock.move` level
and let him manage the `stock.move.line`
closesodoo/odoo#161728
X-original-commit: fa3439e5c595a04e67fa22965d6b10bb1f487f63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
If an order was validated in PoS but encountered a sync error, the
order would revert to a draft state and no receipt would be printed.
However, if an order was validated in PoS without internet, the receipt
could still be printed. When the internet connection was restored, the
system would attempt to validate the unsynced order. If a server error
occurred during this process, the system would try to revert the order
to a draft state and fail. This behavior is not ideal as an order with
a printed receipt should not be modified or changed. This commit
ensures that in the event of a sync failure, the saved orders do not
revert to a draft state.
opw-3858994
closesodoo/odoo#161250
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The cover scss rule first stretches the image to fill the container completely,
then cropped at the size of the container.
This results in some poor display result if the image has a weird aspect ratio.
This is a behaviour change from saas-16.3 where the image wasn't cropped and
simply resized to fit inside the container.
opw-3826349
closesodoo/odoo#161111
X-original-commit: 0cc3a0edfcd68ebbd7930eedd2af82bd3b3a29fe
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Loïc Leloup (lole) <lole@odoo.com>
Some people want to manage the subcontractor stock the same way than a
classic stock. It will then impact the on hand value but it's the
behavior they want.
I keep the constraint on internal location since it will impact
valuation.
closesodoo/odoo#163262
X-original-commit: be8e1da9d9dc3b82479b1560c9d5e780c8ecb36b
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When a DB is duplicated, it's going through the neutralize process
which is helpful to clean stuff that will be messing around with the
duplicated DB.
The CDN should actually be part of that. Since a CDN url is bound to a
domain, when you copy the database (and most likely run it on its own
different domain), it just won't properly work.
Indeed, if you setup a CDN X for domain A and then copy a DB to domain
B, this will happen:
- You access website B
- You try to load an img, which is using CDN X URL
- CDN X URL is fetching the ressource on DB A instead of DB B, which
might or might not exist (an image will likely share the same path so
it might work, but for assets url it might not if the bundle url has
changed)
In the event of the assets having changed, they will never be loaded and
the duplicated DB won't be loading properly.
The only workaround in this case is to switch to debug mode to bypass
the post processing and so the CDN url transform.
Useful commits:
- Introduction of neutralize
https://github.com/odoo/odoo/pull/67825
- Conversion of neutralize from ORM calls to raw SQL
https://github.com/odoo/odoo/commit/e5dbded9bb363351feff7ca8a56c7f8a6860f492
opw-3880102
closesodoo/odoo#163210
X-original-commit: ab6493ae9fff218a43df12829011a4f642902114
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Create an SO with an SOL and save the record.
** The `qty_delivered` of that SOL will be null in the DB. **
Cause of the issue:
Since the `qty_delivered` field is computed, the default value is set in
the DB comes from the `_compute_qty_delivered` method at record creation
However, no default value is set here when the `qty_delivered_method` is
not `'analytic'`.
Note:
In 15.0, a default value was set because of these lines:
https://github.com/odoo/odoo/blob/313418804ae5cb6a786488ffc174b8eebffb796e/addons/sale/models/sale_order_line.py#L350-L353
These were removed by this commit de4911a.
opw-3771589
closesodoo/odoo#163180
X-original-commit: 3e20e293771a252bbdcd395b5a12a2cef70f0218
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The survey.survey_user_input_rule_survey_user_read rule is
override in both hr_appraisal_survey and in hr_recruitment_survey.
The problem arises when both modules are installed. If so, the domain
is taken from the module that is installed the last.
This should not be case, instead domain should be combined.
On top of it, the domain is not corrected when the app is unistalled.
This commit fixes that too
task - 3597033
closesodoo/odoo#163138
X-original-commit: 5d4b5175855041efd6174fe5e35f06ede3b62818
Related: odoo/enterprise#61363
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Allow pos users to have the "internal note" button available even in
non-restaurant shops.
The changes also make sure that the button is disabled when there is no selected
orderline.
closesodoo/odoo#162863
Task-id: 3878947
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
This commit fixes an issue where the `sale_last_order_id` was not being
set in the session when the extra info step was added to the checkout
process. This caused an error during the validation of event payment in
`shop_payment_validate`.
Steps to reproduce the issue:
1. Install `website_event_sale` and set up a payment provider.
2. Add the extra info step to the checkout in the website.
3. Register for a paid event from the website.
4. Proceed to pay the order, which would previously result in an error.
opw-3864873
closesodoo/odoo#162657
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Steps to reproduce:
- Install eCommerce
- Go to My account
Issues:
There is a box "Addresses" which is useless for the moment as it's
the same page that can be accessed by clicking on "Edit information".
The feature to have multiple addresses is going to be present in master at some point, however for now we're removing the box as it's useless.
opw-3869920
closesodoo/odoo#162626
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Install e-Commerce
- Go to your portal into a quotation
- Go to the chatter and send an empty message
Issues:
A traceback is shown
Solution:
Catch the error and discard it as the parent method is already
displaying the error message to the user.
opw-3877096
closesodoo/odoo#162424
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Activate "Analytic Accounting" in Accounting settings
- Switch to a mobile view
- Go to any view where there is the analytic distribution widget (e.g. expense form)
- Try to configure the analytic distribution
Issue:
When an analytic account is selected, it is not taken into account.
Cause:
In mobile view, a modal is opened with a kanban view to select the
analytic account.
Any click on this modal is closing the analytic distribution widget.
opw-3734050
closesodoo/odoo#162092
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Steps to reproduce:
- Create a product with 2 vendors
- Click replenish on the product page and select the second vendor
- The PO is created for the first vendor
Bug:
the replenishment will create a move which will create/edit a PO
the selected supplier is discarded
Fix:
set the partner on the procurement group to keep track of it
note:
'supplierinfo_name' no longer used, will be removed in master
related test ("test_procure_not_default_partner") is now irrelevant
opw-3776680
closesodoo/odoo#161974
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Found error during migration in customer database.
when company is archived but will get that company
on `self.env.company` of pos_config table,
this error is generated when it's try to create the
record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required
and we set default value by fetching warehouse for related company
but here as company is archived, related warehouse is also
archived and that why we didnot get picking_type_id
for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
closesodoo/odoo#162590
X-original-commit: 34b9bf83eeba55c1e05a916064dafcc7a9d7356e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Atul Patel (atp) <atp@odoo.com>
step to reproduce:
1. account journal with `INV` code AND
`FAC` translated code, will get
two journal which was raise traceback
as we have unique constraint raised.
these are two journal with 1. INV code
2. FAC code as translated code
so will get two journal and got traceback
```
select name,id, code from account_journal where id in (12,13);
name | id | code
----------------------------------------------------------------------+----+------
{"en_US": "Factures clients", "fr_BE": "Factures clients"} | 12 | FAC
{"en_US": "Factures fournisseurs", "fr_BE": "Factures fournisseurs"} | 13 | INV
(2 rows)
File "/tmp/tmpwqzy2fx8/migrations/account/saas~16.2.1.2/end-migrate.py", line 50, in migrate
ChartTemplate._pre_reload_data(company, template_data, data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 264, in _pre_reload_data
self.env['ir.model.data']._update_xmlids([{
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2270, in _update_xmlids
rows.add((prefix, suffix, record._name, record.id, noupdate))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 5142, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(12, 13)
```
closesodoo/odoo#163185
X-original-commit: 32b4bd2e146522c3feb03e34d0e9bd3261e37cbe
Signed-off-by: Atul Patel (atp) <atp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When the Manufacturing Order 'qty_produced' is different than the 'product_qty' (we produced more or less than expected), then unbuild order had the wrong quantity for the finished product, and if 'mo_id.qty_produced > mo_id.product_qty', then an extra confirmed move was generated upon the validation of the unbuild order.
OPW-3860612
closesodoo/odoo#163096
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Prior to this commit, the `form-range` track color used the light color.
This created a color inconsistency with the rest of the UI when we
changed the third color.
Steps to reproduce:
- Go to the Shop page.
- Click on Edit.
- Click on the page and make sure "Price Filter" is active in the Web
Editor.
- Go to Theme tab.
- Change color-3 (light) to another one (eg. red).
This commit adjusts the color to maintain consistency with the rest of
UI elements.
task-3702675
closesodoo/odoo#150886
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, checkboxes, radios and switch inputs had a color
issue in frontend: as the inner element (eg. check mark) was always
white if the user changed the primary color to a bright one, the inputs
were no longer readable.
Steps to reproduce:
- Go to the Contact page.
- Click on Edit.
- Click on Theme tab.
- Replace the primary color with a bright one (ex. light gray).
- Click on the form in the page.
- Add a field.
- Select the new field and choose the "Radio Buttons" or " Checkbox"
type.
- Click on Save.
- Check the checkbox or the radio button.
=> The check mark or the dot is not visible enough.
This commit adjusts the colors to ensure that these inputs will always
be visible.
task-3702675
Part-of: odoo/odoo#150886
Prior to this commit, dropdown inputs had a color issue in frontend:
the caret color of `form-select` was dark regardless of the input's
background and didn't provide enough contrast when we defined a dark
background on the page.
Steps to reproduce:
- Go to the Contact page.
- Click on Edit.
- Click on Theme tab.
- Replace the fourth color with a dark one (ex. black).
- Click on the form in the page.
- Add a field.
- Select the new field and choose the "Selection" type.
- Click on Save.
=> The dropdown caret is not enough visible.
This commit adjusts the caret color to make sure that this will be
always visible.
task-3702675
Part-of: odoo/odoo#150886
=== Maintain border consistency of frontend inputs ===
Prior to this commit, `form-select` borders overlapped the background
color, which is not the case with `form-control`.
This is because `form-control` uses the `background-clip` property.
As we're using a semi-transparent border on frontend inputs, this
creates a color issue: when a `form-select` input is disabled, the
border color is darker than that of the `form-control`.
This commit adapts the `background-clip` on `form-select` input to
maintain color consistency between inputs.
=== Make disabled inputs more recognizable ===
Prior to this commit, disabled inputs were not sufficiently distinct
from regular inputs, especially `website_sale` inputs which had a gray
background.
Steps to reproduce:
- Make sure your instance has website_sale_renting installed.
- Go to the Shop page.
- Look for a product with a rental period (eg. Printer).
- Click on Add to cart, this will disable the rental period input.
=> The gray search bar and the disabled input have almost the same style
This commit adapts the style of disabled inputs in the frontend to make
them more recognizable.
task-3702675
Part-of: odoo/odoo#150886
Prior to this commit, the custom dropdown caret in the `website_sale`
sidebar didn't handle the "multiple" attribute,
unlike the default dropdown.
If we decided to add a "multiple" attribute to this element, the caret
remained displayed, which created a design issue.
This commit adapts the caret of this dropdown so that it works
correctly when this attribute is defined.
task-3702675
Part-of: odoo/odoo#150886
Single value graph were not shown in cumulated graph.
This is due to unshift happening before the accumulator,
leading to `undefined + X = NaN` for the value.
closesodoo/odoo#162385
X-original-commit: 121aa7e02235c5117bf6be6ccc6c8d6cefe6a744
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Florian Damhaut (flda) <flda@odoo.com>
Usecase to reproduce:
- Product wiht a real time valuation
- Product with invoice on delivered quantity
- Create a SO for 5 units and 1000$ each
- Do a full downpayment of 100% of quotation
- Deliver 3 out of 5 units and create a backorder
- Create an invoice
- Validate the invoice
Expected behavior:
The cogs entries are there
Current behavior:
No cogs
It only happens with partial downpayment. When the downpayment amount
equals the quotation amount. An invoice is created instead of a credit
note and the process works correctly.
It happens because it creates a credit note with a negative quantity to
invoice so the system doesn't understand it has to create the cogs at
that point.
closesodoo/odoo#161768
X-original-commit: d2a365c2ee9af6a9272d83183fc75fa6914bc560
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Install POS app.
- Go to POS settings and enable:
- Is a Bar/Restaurant
- Tips > Add tip after payment
- Open a POS session -if first time, add a floor and a table-
- Add a product
- Click on payment
- Choose a payment method
- Click on Close Tab
- The print popup is shown twice in a row with an empty subtotal amount.
Investigation:
- Inside the `TipReceipt` template, the `total` is not shown as the class lacks a getter for it [1]
- Also when there is no printer, we won't fallback to the web printer as it's annoying to the cashier.
[1]: https://github.com/odoo/odoo/blob/1d49034782e3ff0e4384bad4e927a895e2a97839/addons/pos_restaurant/static/src/app/tip_receipt/tip_receipt.xml#L13-L16
opw-3836549
closesodoo/odoo#161056
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options`
in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
closesodoo/odoo#163123
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Create a Vendor Bill
Add on the invoice line a vehicle
Confirm
In "Journal Items" tab hit 'Cut-Off'
Fill the necessary info and create journal items
Issue: Created journal items will not have the vehicle id
opw-3802919
closesodoo/odoo#163054
X-original-commit: 68c21eca068b1762392466101b0b4c220bce7ab5
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Problem:
when configuring a provider (from the form view) in shipping methods, after:
* setting the provider to "Fixed Price"
* setting the `free_over` / `amount` field
* changing the provider to "Based on Rules"
the `free_over` / `amount` still applies even though the field becomes
hidden.
Desired behavior after:
When the provider is "Based on Rules", ignore the `free_over` / `amount`
if it is set (but don't unset it, still hide it in the view).
Fix of merge conflict
opw-3852858
closesodoo/odoo#162980
X-original-commit: ac12bf394bf34265e2ee5a089a122236fcc486bf
Signed-off-by: Nathaniel Jacques (naja) <naja@odoo.com>
Current behavior:
When trying to create an expense using alias, if there's several `hr.employee` linked to a user, it select the first one instead of this with the right company
Steps to reproduce the error :
- Create different employee's profiles for a same user
- Put the default one on the user's profile (don't put the first that you created because it will select the first for the expense)
- Try to send an email to the expense's alias and check at the logs
After this commit:
The right employee (this one in the default company) will be selected and no error will be triggered
opw-3754015
closesodoo/odoo#162923
Forward-port-of: odoo/odoo#161853
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Cameron Noupoue (cano) <cano@odoo.com>
Original issue:
1) Create a company "main", with 2 branches: "A" and "B"
2) Create a sub-branch for "A": "A1"
3) Archive company A
4) In the company selector, make "main" the active company. It will auto-select branch B as well.
5) Open the tax report, and try clicking the "Closing Entry" button
==> The button is disabled ; it shouldn't be.
This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches_with_same_vat searches for sub-branches, doing
self.env['res.company'].sudo().search([('id', 'child_of', current.root_id.ids)])
In our example, this search will return main, B and A1. We then compare that with the company selector, which only contains main and B.
This configuration of companies does not make sense functionally speaking, as a branch whose parent is inactive will not be usable anyway. Therefore, we now archive all the sub-branches when archiving a company.
opw-3877368
task-3878070
closesodoo/odoo#163078
X-original-commit: b5f297616e937535f2d0ba3f05fd905858741d53
Signed-off-by: William André (wan) <wan@odoo.com>
The test needs to set `product_id` field in order to check user's
access. However, the field is not visible without enabling product
variants, which makes the test fail in an environment with no demo data.
This commit fixes the issue by adding the MRP manager to the
'product.group_product_variant' group.
The issue was introduced in #162107 .
Related build error:
https://runbot.odoo.com/web#id=61998&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=formclosesodoo/odoo#162873
X-original-commit: 00b317b114cd139a4ea03a1e660e1b549f829130
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Pawel Fertyk (pafe) <pafe@odoo.com>
Before this commit, when user set privacy as 'Available' from odoo it is not
properly synchronize in google calendar.
After this commit, privacy value changes will be properly synchronized when
changes will be made from odoo to google calendar.
task-3667696
closesodoo/odoo#162486
X-original-commit: 888e65c9ff08866a7cda2cdf2e2b8c766fb773ca
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Context: in 17.0 we enabled mass download for invoices.
We expect this download to create a zip with all PDF invoices
and their related xml files.
Steps to reproduce:
1. Install l10n_fr
2. Create two invoices to french partners
3. Send & Print the two invoices and select 'Factur-x" and "Download"
4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml"
Cause:
The name of the XML file for the factur-x XML file is not specific to related invoice,
it gets overriden each time it is generated.
closesodoo/odoo#162406
See: https://github.com/odoo/odoo/pull/137382
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Until now, it is impossible to do <g:title>xxx</title> because qweb
will autoclose the <g:link> because it checks if link is a void element
instead to check g:link.
Now we check the el_tag instead of unqualified_tag.
closesodoo/odoo#159476
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Reported issue:
Steps to reproduce:
Be sure that 'industry_fsm' is installed.
- Go to Project > Projects and swap to the list view
- Create and save a new project with a customer
- Access the related SO via the smart button
- Add a service product, a storable product a section and a note
- Go back and access the project status with the smart button
> The SOL generated for the section and the note appear as SO items
Expected behavior:
The purpose of the project status tab is to have an overview at the
project to help in the analyse its profitability, the time investment,..
as such, these SOL should not be considered as SO items. In addition,
these lines lose their entire purpose in the list view used in
this overview (they can not be moved and display irrelevant infos).
Cause of the issue:
These lines were not filtered out by the current query.
opw-3794386
closesodoo/odoo#157984
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Before this fix, any XRechnung xml will raise a warning when being
submitted on https://erechnungsvalidator.service-bw.de/.
The warning states: "[BR-DE-21] Das Element "Specification identifier"
(BT-24) soll syntaktisch der Kennung des Standards XRechnung
entsprechen."
This is because the version 3.0.1 has been released.
issue-160644
closesodoo/odoo#163064
X-original-commit: 7dd7ab08888c8ba85603734c6481cfc4cbd17e87
Signed-off-by: John Laterre (jol) <jol@odoo.com>
In some databases, customers have changed the `reconcile` value of
an account from its standard `False` value to `True`.
This action causes related journal items,
which are partially reconciled, to raise the following
constraint error.
during the upgrade process:
```
You cannot switch an account to prevent
the reconciliation if some partial reconciliations are still pending
```
so we delete changes in the `reconcile` values from the reload
to avoid overriding user customer setting & triggering the
constraint error.
closesodoo/odoo#163020
X-original-commit: 0a4bd1e6d4b76d113b30d2b19fee8408c0988d93
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Problem
---------
Because of this PR: 155896, the customer default value for the UBL
export values has been modified from commercial partner to partner.
However, in 16.0, some constraints have been added to verify that some
fields were properly set up before generating the XML. Those
restrictions clash with the said changes.
Indeed:
1 - Create NO company
2 - Set up UBL on invoice journal
3 - Create a new NO customer and set up UBL in the same way
4 - Create an invoicing address for that customer
5 - Create an invoice for with the customer set as the invoice address
set up in step 3.
6 - Send & Print with UBL selected
>> An error is added to the export errors while it should not.
Solution
---------
Use the commercial partner when checking constrains of all fields other
than addresses.
OPW-3848367
closesodoo/odoo#162591
X-original-commit: cb1ed8d37ee276b806e6fe874c348a2a434fd1e9
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Surveys cannot be created in batch without `session_code` because it must
be unique across surveys.
Technically, using a 5-digit codes makes it unlikely that
a collision occurs with records created without explicit session_code (see
Survey._get_default_session_code's iterative process).
See runbot 55709
See also related runbot 25041 solved in #159295
Task-3829536
closesodoo/odoo#162587
X-original-commit: 0efbd6e31f5870c1e3004c129e79b9dfa7379863
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The various keys and certificates used by the TestIrMailServerSMTPD test
suite were generated on-the-fly via a shell script present next to the
test. It is just easier to save the keys and certs in git rather than
re-generating them everytime.
Changed the private keys from RSA to ed25519 for the smaller files size,
changed the validity date to a thousand year.
task-3703209
opw-3640374
Part-of: odoo/odoo#151483
A previous commit broke the smtp authentication using a TLS certificate
and we only figured it out after that a client created a support ticket
several weeks later. It turns out that there are no tests that validate
the various ways outgoing mail servers can be configured.
In this work, we add a test suite where a local smtp server is started
and controlled during the test execution. This makes it possible to test
all the possible outgoing mail server configurations, including TLS.
This work revealed several problems that have been sorted in other PRs,
a problem that is left to solve is to verify those certificates as shown
by the `test_man_in_the_middle` test. This will be sorted in a future
work.
We chose [aiosmtpd] which is a pure-python lightweight SMTP server that
aims at providing a programming API that is well-suited to be used
inside unittests.
task-3703209
opw-3640374
[aiosmtpd]: https://aiosmtpd.readthedocs.io
Part-of: odoo/odoo#151483
Issue:
======
If you have some tabs in a html_field, opening with a different browser
may cause an issue when saving the document layout.
Steps to reproduce the issue:
=============================
- Open with firefox
- Go to settings , document layout
- Added some `tab` in the footer or any html field
- save
- Open with chrome
- Go to settings , document layout
- click save without doing anything
- error
Origin of the issue:
====================
When calling sanitize in the constructor, the tabs size doesn't change
because we didn't add the class `odoo-editor-editable` which doesn't
make the `editable` dirty since no changes has been made. When calling
save, `cleanForSave` will be called with a clone of the `editable` so in
sanitize it won't matter since the element is not connected to the dom
so again no changes and the edtior still no dirty, after that ,
`onWillUpdateProps` of `Wysiwyg` will be called and we will set the
value of the editor by the new value which will call `resetContent` of
`odooEditor` and it will sanitize the editable but this time it has the
class `odoo-editor-editable` so the finally the sizes of the tabs will
be changed and the editable will become dirty. Now `onWillUnmount` in
`html_field` will be called and since the field is dirty it will commit
changes as a normal save , but a traceback will occur since the
component is already destroyed.
Solution:
=========
Add the class `odoo-edtior-editable` before the call to sanitize to mark
the field as dirty from the start and will be updated with the new sizes
of tabs on the first commit and not in the commit of `onWillUnmount`.
opw-3742423
closesodoo/odoo#156898
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG)
will cause a traceback because img.image is
not populated when there is an empty source, SVG, or WEBP file uploaded
as this code should not be reached with these file types.
The reason this occurs is because we check for the file extension when
deciding to post process an image, but when we get to initializing the
ImageProcess object, we then check the actual file structure to verify
the type of file.
This is a workaround for the time being, but should not be a final
solution in future versions.
Adding a null check on img.image in the _postprocess_contents method
in order to avoid attempting to access the size of this image when it is
null.
Raises a user error in order to trigger the catch and exit the code
while logging the error and 'Post processing ignored:'.
Includes test for this new workflow with no errors.
opw-3672250
closesodoo/odoo#162976
X-original-commit: e9750b16a61c3598f7a2b14a1552fcb4ecf1a293
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Ryan Cen (ryce) <ryce@odoo.com>
This commit is a performance fix to improve the speed of opening the pos kiosk or QR code.
`_get_attributes` method of pos_self_order's product.product extension will call `self.env["pos.session"]._get_attributes_by_ptal_id()` every time it is called. For *N* products, `_get_attributes` is called *N* times. This can lead to slow performance for high enough *N*, because `_get_attributes_by_ptal_id` method is slow, because it makes many `read` calls to product.attribute.value
This commit lifts the call to `_get_attributes_by_ptal_id` higher in the call stack, so that it is only called once as opposed to *N* times. It passes its result into `_get_attributes` via context, which will re-call `_get_attributes_by_ptal_id` if it wasn't in context for backwards compatibility reasons.
attributes must be deep copied within `_get_attributes`, because `_add_price_info_to_attributes` mutates the values within, which would invalidate future calls. The deep copy gives a fresh instance for each call, and only copies the applicable attributes so it shouldn't be large.
In this particular customer's DB they have 1376 product.product records and their pos config's pricelist (id 36) has 1572 rules in it.
Overall, based on the benchmarks below, this commit makes loading the pos about 4-5 times faster.
Benchmarks:
__Before commit__
_Customer DB_
product.product count == 1376
SQL query count ~= 5034
Time to load pos ~= 44 sec
_Customer DB with more products_
product.product count == 3792
SQL query count ~= 9359
Time to load pos ~= 96 sec
__After commit__
_Customer DB_
product.product count == 1376
SQL query count ~= 2360
Time to load pos ~= 8 sec
_Customer DB with more products_
product.product count == 3792
SQL query count ~= 3906
Time to load pos ~= 22 sec
closesodoo/odoo#162962
X-original-commit: f09db068ff3c5a4e8444885c0cdd28e4221cf024
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Zachary Hanham (zaha) <zaha@odoo.com>
The module `l10n_nl_reports_sbr` requires
- `zeep.wsdl.utils.get_or_create_header`
- `zeep.ns.*`
- `zeep.wsse.*`
In addition, it requires the `session` to be already
set during the creation of the client.
The module `l10n_pe_edi` requires `requests.Response` as possible
output for service
```py
result = client.service.sendBill
if result.status_code != 500:
...
```
Can be tested with
`--test-tags external_l10n:TestEdiSunat`
opw-3887309
opw-3884785
opw-3885630
opw-3870707
opw-3888951
opw-3885636
opw-3885392
opw-3885383
opw-3889366
opw-3888841
yosa-odoo