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>
Issue: Error when the 'date_from' field is left blank.
Cause: When deleting the 'date_from' field, the onchange
'_onchange_date_from' is triggered. It will call the
'_process_accrual_plans' function and report an error as shown below:
first_level_start_date = allocation.date_from +
get_timedelta(first_level.start_count, first_level.start_type)
TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'
Solution:
- Check the 'date_from' condition before calling next function
- Handle it only in the onchange because the 'date_from' field is
required
closesodoo/odoo#162730
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Fix the demo user input lines which were considering "Pinaceae"
as a correct answer to the question "Dogwood is from which family
of trees ?" even though the suggested answer was declared as incorrect
for the question.
Dogwood is indeed from the "Cornaceae" family of trees, not the "Pinaceae".
Fixing the issue by updating the user input lines to be incorrect.
related: odoo/odoo#72298
Task-3856668
closesodoo/odoo#162886
X-original-commit: ee9ce57f4bb63d1c311d9474c26626081f333ba4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Amélie Dieudonné (amdi) <amdi@odoo.com>
using sudo().is_kits to account for user not having access
to the bom module and boms in different companies
closesodoo/odoo#162830
X-original-commit: badd0a6dce90cc103ebc2c193e47da3f753f80a6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Current Behavior:
Tasks with or without dependent tasks and a state not in closed states have their state changed to `01_in_progress` when duplicated.
previous PR that changed this logic: #139249
Purpose of this PR:
To retain the state of the original task when duplicated.
Steps to Reproduce in Runbot:
1) Enable Task Dependencies in Settings
2) Create a Project with Task A
3) Set state of Task A to 'Approved'
4) Duplicate Task A > Task A will now have a state of 'In Progress'
opw-3836251
closesodoo/odoo#162794
X-original-commit: a50d0317732232dad6c4b8b65c985643d0ff94b5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
While searching for a similar attachment, as the fallback url pattern is
the same as the url pattern, the condition is never satisfied.
With this commit, the ignore_params parameter is used to find a similar
attachment.
closesodoo/odoo#162654
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
A few x2many list embedded in form views have the "editable" attr
set to "1". Normally, the valid values for this attribute are "top"
and "bottom". Regular list views are validated, but not lists
inside form views.
When set to "1", some features of the model aren't enabled. For
instance, when the current page is full and the user adds a record,
the limit isn't temporarilly increased for the added record to be
displayed on the current page, like it would be in editable="bottom"
lists, so the user doesn't see the record he just added.
The issue can be observed in the stock move form view for instance.
This commit is only good for stable versions: we add a fallback
on "bottom" s.t. if the editable attribute is set, it's always
either "top" or "bottom".
In master, we'll probably rethink the API.
opw~3860903
closesodoo/odoo#162832
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit fixes an issue occurring in the `web_editor` when multiple
users edit some content.
Prior to this commit, the user avatar was not using any aspect-ratio
rule, resulting in a stretch avatar if the uploaded image wasn't square.
This commit fixes this issue by adding the `o_object_fit_cover` class to
the image, ensuring a correct ratio no matter the format of the uploaded
image.
task-3877841
closesodoo/odoo#162810
X-original-commit: 7240fa3ff495a8aba7bd53b720e99cd767948342
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Access rights on ir.attachment depend on the record it is linked to.
steps to reproduce:
- log as admin
- create a calendar event and invite marc demo
- log as marc demo
- check discuss notifications and try to download "invite.ics"
before this commit:
- file can not be downloaded from the webclient (access error appear in logs)
after this commit:
- file can be downloaded from the webclient
opw-3754798
closesodoo/odoo#162694
X-original-commit: 6a698ef3ee99af45251156279c9a5af6185f5dd1
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
The `use_create_components_lots` option of manufacturing picking type was never read
as the context to get the active production order was not always
specified.
Also, this field was not taken into account to display or not the
'generate serial' and import 'lot buttons'
closesodoo/odoo#162581
Related: odoo/enterprise#61137
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The FEC report contains initial balances. These representing balances on accounts from the previous period.
When calculating the initial balances, there is no requirement to include balances from the previous period for an account if they are at zero.
When there are settled transactions for many thousands of partners from the previous period, this results in many thousands of initial balance lines in the FEC report that all have a balance of zero.
This PR remove initial line with zero balance.
closesodoo/odoo#160729
X-original-commit: 1d1beaf4aa02875f1843b99564562f9ed4446ae8
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
A lot of users don't understand why they can't reserve in MTO chain after
moving a product with an immediate transfer. It's due to the double check of
_action_assign that look where the move orig stored the product and
if the quants exist in this exact location. In our case the product was
moved so the match doesn't work.
We introduce an new parameter to check if modifying the behavior on
those cases could work. When _free_reservation is call on a
`stock.move.line`, we expect to never find it at this place
anymore (except if we bring it back). Then we drop the MTO link
for this step and use the MTS reservation.
WARNING, this parameter could remove too many mto links. e.g.
There is multiple stock.move.line linked to different locations
they will lose the link for product remaining in the same place.
closesodoo/odoo#155118
X-original-commit: af41b538d89a3c59c78f65c9174c7fbf4aa43922
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Andrea Grazioso (agr-odoo)