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
This test can sometimes fail randomly
FAIL: TestProfiling.test_sync_recorder
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder
self.assertEqual(stacks_methods, [
AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']]
First differing element 11:
['__exit__', '_remove']
['__exit__', 'stop']
First list contains 2 additional elements.
First extra element 12:
['__exit__']
[['a'],
['a', 'b'],
['a'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a'],
[],
['__exit__'],
- ['__exit__', '_remove'],
- ['__exit__'],
['__exit__', 'stop']]
Since we don't care about the last lines, just remove them from the
assertion.
closesodoo/odoo#163016
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Those were broken by the theme update for 17.0, in particular at [1].
Indeed the underline colors were defined using `text-XXX` classes to use
the theme colors, relying on the fact that the default color of HR
elements used the `currentColor`. Now they use the `currentColor` but
very faded... making those underline colors uglier and for one of them,
basically invisible.
As a stable fix, this updates the XML to make the border use the
`currentColor` as before in new mega menus... although they do not work
as well in 17.0 as they did in 16.0. This will be reviewed in master to
use better colors and a more reliable and beautiful way.
[1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364eclosesodoo/odoo#163011
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
All these countries use the chart of accounts that is defined in l10n_syscohada.
This commit then add the tax report for each localization, and taxes to be able to fill it.
task-2841655
closesodoo/odoo#136155
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Issue:
Have a grouped list view with several pages, go to the next page,
open a group and click on a record to open it in form view. Click
on the breadcrumb to go back to the list: the offset is lost, and
we're back in page 1.
After this commit, the offset is correctly kept.
opw~3851390
closesodoo/odoo#162969
X-original-commit: 8dbf154fdbbff7790c99b3f91d3c1896d436a346
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue:
======
Colorpicker doesn't appear in mass mailing
Steps to reproduce the issue:
=============================
- Create a new mass mailing with a some template other than plain text
- Try to change the color of some text
- The position of the colorpicker is wrong.
Origin of the issue:
====================
When wysiwyg was converted to owl in [1], an effort was made to
speed up the loading of the iframe in mass_mailing. One of the
changes that were done in that regard was to remove assets from
the iframe to make it load faster. This required to create the
sidebar (SnippetsMenu) outside of the iframe since the iframe did
not have the required files anymore, and insert it back in the
iframe afterwards, since it was designed to work inside the iframe.
This change actually had an impact on the positioning of the
colorpicker, and basically anything that relied on popper.js for
positioning, because since popper.js was outside of the iframe then
the checks it did based on `instanceof HTMLElement` were returning
false for every node inside the iframe. At the time of [1] this
went unnoticed because the chatter was not yet in the side of the
screen for mass_mailing, so the wrong positioning of the colorpicker
was actually only slightly off the right position, thus being hard
to catch while not specifically looking for that particular issue.
As soon as the chatter was made to be on the side even in the case
of mass_mailing, the wrong colorpicker position became visible but
the issue went unnoticed at the time as well, probably because the
two changes were completely unrelated. This went live in saas-16.4
and is the case in 17.0 as well. However, the issue does not exist
anymore in saas-17.1 due to the refactor of mass_mailing to have
the sidebar (SnippetsMenu) working from outside of the iframe
instead of inside.
Solution:
=========
Fixing this issue properly would require huge changes to how the
SnippetsMenu is constructed and would most likely require going
back to the slow iframe with all the assets inside. That would not
be a desirable outcome, especially in a stable version. With that
in mind, and considering the issue doesn't exist in saas-17.1, we
decided it was a prime example where a local change in the popper.js
library was actually the best fix. The library is very unlikely to
be updated in a stable version and the change won't reach saas-17.1.
[1]: https://github.com/odoo/odoo/commit/76d4f98
co-authored with dmo-odoo
task-3614965
closesodoo/odoo#162964
X-original-commit: 88c16966b6b2d29d464ac3b43cc4998d3f4fe0e2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Prior to this commit, there were scenarios where sync orders did not
contain an order, leading to a failure when reading its state. This
commit introduces a check to ensure the order exists in sync before its
state is read, thereby preventing this error.
opw-3856451
closesodoo/odoo#162943
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since commit 7d2baaa0c7 ("Unity read"), we are able to
pass a full specification to subfields in a view and retrive records directly according to that
specification. This could include "order".
In the case of a list view that has a `widget="handle"`, this order is automatically set to "[handle_field] ASC".
Before the unity read feature, it did not cause problems for one2manys because the ids of records were retrieved in python
using the "natural order" of the model (the `model._order` slot), which usually had the right parameters.
(see `sale.order.line` for example). When fetching the ids of the one2many, those were already sorted in natural order.
In unity read, the natural order is overriden by the specification and became only "[handle_field] ASC". This was insufficient
as more often than not, sequences on model are set up with a default. So eventually, all records couls have the same sequence.
The sorting in SQL becomes undeterminate.
After this commit, we had the sorting key "id ASC" to avoid any unwanted results.
opw-3790378
see discord https://discord.com/channels/678381219515465750/687338039717920792/1231977078564585555 for a detailed discussion.
closesodoo/odoo#162933
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Step to reproduce:
- Go to /jobs (install website_hr_recruitment)
- Go on a job offer
- Click on the "Apply" button
- Edit the form
Purpose:
Since the implementation of commit [1], our system employs alerts
resembling `this field 'partner_name' is mandatory for the action
'actionName'`. However, this alteration has led to a bug where in
certain forms exhibit an undefined action name value, particularly
evident when users attempt to modify specific forms containing required
fields. The bug manifests when an alert is triggered, and the action
name becomes undefined due to the condition `this.modelCantChange`
evaluating to `true` within the `willStart` function. Consequently,
invoking `_super` results in the return of `willStart` without assigning
a value to `currentActionName`.
After this commit:
Now, before returning the function, it sets a value for
`currentActionName` and then proceeds with the necessary steps. This
prevents the issue where an action was `undefined`.
[1]: https://github.com/odoo/odoo/commit/b154fe1
task-3680483
closesodoo/odoo#162468
X-original-commit: 3626e36a9c4995286be48206b0d927f1de51e295
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Current behavior:
When trying to print a receipt offline, the image will not be loaded
and you get a traceback.
Now the receipt is printed, and an error is logged in the console if
the images couldn't be loaded
Steps to reproduce:
- Add a logo to the company
- Launch PoS
- In the browser devtools network tab turn the connection down
- Do an order, and try to print the receipt
- You get a traceback and the receipt is not printed
opw-3811663
closesodoo/odoo#162451
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the module "sale_product_configurator" is not installed, an AttributeError is raised
Steps to reproduce:
Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module
Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface
Cause:
The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module
opw-3850421
closesodoo/odoo#161921
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently when we have an Analytic Filter applied on an accounting
report, we lose that filter when we click on any amount to audit the
journal items.
This fix makes sure that when auditing, we only view the journal items
filtered by the Analytic Filter.
In order to do that, we extend the search function in the analytic mixin
to allow searching on analytic account ids.
task-3718751
closesodoo/odoo#161873
X-original-commit: 2e3be9726514f74ea8c0c2314c9cdfeb6ed57915
Related: odoo/enterprise#60742
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
forward ported the commit https://github.com/odoo/odoo/commit/cbefaa6bff5bab6c787d8b9ef4668ba7d9870d55
In odoo#126249 the german balance sheet report was updated and
during the 15.2 FW port, some issues needed fixing. The
issues and their fixes are:
- Deleted tags: As the script didn't run, some tags (like F and
all D tags) would be deleted and not renamed. As the tag might
already be used as a FK in another table, we remove it from
ir_model_data so it's not deleted by the ORM. Also, this means
that the tags xml adds the B1 as a new tag which means renaming
C1 to B1 will not work in the script due to the unique name
constraint, this is handled by checking if B1 exists and if
it does we do not run the script.
Enterprise PR: odoo/enterprise/pull/45899
closesodoo/odoo#162436
X-original-commit: c019d6f3f5cfe3884ba10fd1aa9357dabe592db8
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps to reproduce the bug:
- In Website edit mode.
- Drag & drop a "inner content" search snippet into the footer.
- Save the page.
- Enter the letter "h" in the input.
- Bug: The dropdown doesn't adapt properly and increases the height of
the page.
This commit fixes this issue by detecting if the searchbar menu
overflows at the bottom of the page when it's open. If it does, we
reduce its height, and if it still overflows despite the reduced height,
then we move it above the search bar instead of below.
task-3751401
closesodoo/odoo#160426
X-original-commit: d6fb56556c08a1c3aac5951991d40d403e235b90
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Reduce the survey questions page in every display mode
and the print page display to be the half screen size.
This is done to match the previous results page improvements.
Also reducing the font size of the "Thank you" message and the
print page questions and sections titles to best match the new
half screen display.
Removing the badly placed livechat from the survey main layout as
it is overlapping the survey navigation.
The current "no_livechat" variable in the survey main layout and the
user input session layout is not taken into account.
This is due to the fact that, in the "website_livechat" module, the check
for the "no_livechat" variable is performed inside the "head" tag,
so way before the "div[@id='wrapwrap']" element.
Changing the xpath so that the "no_livechat" variable is correctly defined
before the check.
related odoo/odoo#152263
Task-3789479
closesodoo/odoo#156665
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, several qunit load state tests sometimes
failed. They all follow the same pattern:
- trigger an "hashchange" event to simulate an update of the url
- wait twice for nextTick
- check the DOM reflects the url change
However, waiting for 2 ticks isn't enough. Indeed, when the url
hash is set, our mock location object dispatches a "real" hashchange
event on window, but it does it after a setTimeout [1]. Then, the
webclient is notified (via the router service) of the url change,
and reacts by loading the appropriate action. This then requires
2 ticks, because we first clear the DOM with the BlankComponent,
and then we mount the requested action/view.
This commit makes those tests more robust by waiting for a
setTimeout before the 2 nextTicks.
[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52
Runbot issue~37030
closesodoo/odoo#162939
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce the issue:
- Create a storable product “P1”:
- Route: dropship
- Vendor: Azure interior and deco addict
- Create a sales order with one unit of P1
- Confirm the sales order
- A purchase order is generated with a dropship-picking
(linked to the SO)
- Create an alternative PO and confirm it
Problem:
The alternative PO is linked to the SO, but the dropship-picking is not
linked. This is because the procurement is not propagated when creating
the alternative PO.
opw-3828132
closesodoo/odoo#162815
X-original-commit: 727eae85cf532e2b7057a5645550e67875c37d62
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Christophe Monniez