Oversight of: 129b91027700313066db0305876adcf9b2a3817d
If the view is not up to date, it will not display any agenda locations.
We need to keep the 'locations' key into the returned values for code
retro-compatibility.
Task-2942630
closesodoo/odoo#97751
X-original-commit: 6c72297e72e0936e5564f175dcb1716057e0ac4b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since [1] when the search bar was refactored, a search facility was
added on website pages and the rendering of those search results did
not correctly handle the HTML escaping.
This is related to the fact that the `ir_ui_view`'s `arch_db` field is
stored with this double escaping on text nodes, which is done by
`wysiwyg.js` through the `_getEscapedElement` method since [2].
This commit unescapes the last layer of `&` before extracting the
page's text for generating the search results.
Steps to reproduce:
- Add some "&", "<" or ">" characters in a page.
- Use the search snippet to lookup for the page.
=> The results in both autocomplete and the results pages display the
content with an extra unwanted escaping (&...)
[1]: https://github.com/odoo/odoo/commit/9f9c4bb7e40233e633f97c60fb00ae191e9077af
[2]: https://github.com/odoo/odoo/commit/f5acea7f9ce232773ec3adf1828a3d18bbedee1e
opw-2908645
closesodoo/odoo#97748
X-original-commit: 2b95dcdb0d8b49bac8ee38a8d062112468124012
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since removing the "Styles" option and the CSS that went with it,
there is an issue with the center alignment on icons.
Indeed, having a fixed width/height value on `fa.rounded` allowed the
icon to be centered along with its background.
By removing the fixed with/height values, the center alignment
(using `.mx-auto` and `.d-block`) would center the icon but stretch the
background color to the full width of the parent.
To achieve the same result, the cheat is to set the
default value of the wrapping block to text-center and remove
`.mx-auto` and `.d-block`.
closesodoo/odoo#95974
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This theme was using a static image which was designed in a triangle
shape but could not be edited with the `Shapes` option.
In order for the user to be able to change the shape of this image,
much like in the previous commit, a square version of the image is used
as an `original-src`, and the triangle version of it is used as `src`
in the theme.
task-2836942
Part-of: odoo/odoo#95974
As mentioned in the previous commit, the circle in the `Styles` option
has been replaced by a shape.
Previously we used `.rounded-circle` on images to make them round,
now we use the new circle shape from the `Shapes` option to achieve
the same effect.
This change has been applied on the snippets' images.
Snippets containing icons with these options have also been modified.
In the builder, the `Shapes` option generates a second image (circle)
from an original source (square image) and applies various
data-attributes.
In order for the option to function correctly on snippets,
the different data-attributes such as `data-original-src` and
`data-shape` have been added manually to the snippet's images.
This creates a need for an original image and a shaped version of the
image in the repo.
task-2836942
Part-of: odoo/odoo#95974
The `Styles` option contains styles which are unsupported in
emails. The few that are supported can be replaced by other options.
- Shadows: unsupported;
- Rounded rectangle: (unsupported in Outlook)
is replaced by the `Border` options which allows to customize the
border's radius more than the current option.
- Thumbnail: can be done with a combination of `Border` and `Padding`
- Circle: can be done with a shape
(which has been added along with other new shapes)
This option could be found on images and icons and has now been removed.
CSS styles in the `theme_default` file have also been removed since
they are no longer needed.
Three basic shapes (circle, triangle, "slanted" rectangle) have been
added to the `web_editor`'s `Basics` shapes page.
A condition was previously set on the page to avoid showing an empty
page. The condition is moved to each of its buttons instead, so that
new shapes added via xpath from `mass_mailing` to this page are now
visible.
task-2836942
Part-of: odoo/odoo#95974
Before this commit, the tour test_image_upload_progress was failing
inconsistently at the step "check that the file was correctly uploaded"
during the upload of a single image.
[1] adapted the upload progress toast to owl, but it used a state
variable isVisible, updated with a useEffect hook called on change of
the file props. This was not optimal: the visibility could be updated
directly through a reactive variable from the upload service. Instead of
automanaging its visibility, the component is completely driven by the
upload service.
This small optimization is useful in regards of the implementation of
the TourService.
As it is implemented now, the TourService works this way:
When it completed a step, it will check for the tooltip of the next
step, in the next javascript call stack.
If it does not find it in the DOM at that time, it will listen to the
mutations and wait for 750ms after the last one to check again.
Here, as the progress toast was rendered visible not directly when
uploading a file, but after another render, after the useEffect was
executed, the progress toast was sometimes not found directly after
playing the step sending the 'change' event. Then, the TourService was
waiting for all the mutations to execute (the progress toast appears,
the media dialog closes itself, the toast hides itself) and check again
after a delay. But by then the toast was already hidden.
With that, the tour steps are rewritten to follow the flow:
- Open the media dialog in single upload mode
- Upload an image
- The toast is shown
- The media dialog is closed
- The toast with "The file has been uploaded" is still there
- The toast autohides
Also, the file input value is reset after uploading files, otherwise it
was not possible to upload the same file twice (the 'change' event was
not triggered).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
runbot-4117
closesodoo/odoo#95890
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tour .test_03_backend_dashboard was failing inconsistently with a
"failed to fetch" error (which happens when fetching the frontend
assets, from the iframe).
The test is adapted to start directly in the backend, which seems to
prevent that error from happening.
It is also adapted to [1] which was merged during the investigation of
that error.
[1]: https://github.com/odoo/odoo/commit/985e49bdb5e22fa197ba267aa41d7a8ba7e50550
runbot-4418
runbot-4003
Part-of: odoo/odoo#95890
An error occurs when importing the Italian edi xml it the partner bank
account number is defined and the database is configured in such a way
that one partner has multiple res.partner.bank records, with the same
acc_number. This is possible in V14, since the constraint is:
'unique(sanitized_acc_number, company_id)'
meaning that the same bank account on the same partner can occur
multiple times (with different company_ids).
Since the domain of the search performed in the import function didn't
specify the company id or a limit, upon assigning the partner_bank_id
with the values from the search, an expected singleton error occurs.
This has been solved by altering the search domain to include only
partner bank accounts where the company id matches that of the invoice
or where the company id is None (which is technically possible, though
unlikely). A limit of one has been added to the search, and the results
are ordered by company_id, which will result in the res.partner.bank
with a company_id being selected before the one with no id.
This relates to a ticket:
closesodoo/odoo#92881
Task-id: 2854284
X-original-commit: 8cf535a240dea12a5a8b1e0ef3b5b82698379bf1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
*: microsoft_outlook, website_twitter
Steps to reproduce:
- install the google_gmail, microsoft_outlook and website_twitter
modules
- go to Settings > General settings > Discuss > External email servers
- for the twitter module go to Settings > Website > Features > Twitter
roller
- the client secret fields are visible
This commit changes the fields types into 'password'.
opw-2936506
closesodoo/odoo#97722
X-original-commit: 18a792ee21441a2e07cef5997368e6d1a268f46c
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: stcc-odoo <stcc@odoo.com>
This old file is indented with tabs instead of spaces.
This is a problem because the file is using as template to
write new localization.
closesodoo/odoo#97718
X-original-commit: abedeb1fe4705c8e4d36cf7f9d61c61ca2b924dd
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, it was impossible to correctly save a record
containing an invisible required field in its template.
Problem:
When a record tries to be saved or switched to readonly, it will check
the validity of all its fields and if any of them are invalid, it will
cancel the save or switch to readonly. In our case, we have an invisible
required field. If this field is invalid, it is impossible for the user
to modify it because it is invisible. So he cannot make it valid. So it
is not possible to save this record or to switch it to readonly mode.
Solution:
We no longer check the validity of invisible fields.
How to reproduce:
- Go into a list view with a template containing a field that is
invisible and required
- Click on Create
- Click on Save after editing the record
Before this commit:
The record doesn't save itself and doesn't go into readonly mode
After this commit:
The record is saved and in readonly mode
We have the same problem in the form view.
closesodoo/odoo#97610
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fix a typo in a default / field name for SMS composer.
Task-2613245 (Server actions mail update / cleaning
closesodoo/odoo#97757
X-original-commit: 835c68e574ebae5980f57c53dc3c9fd1cd1707c1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the product_tmpl_id field was present in the
product_pricelist_view but not the product_pricelist_view_inherit.
This changes allows to have a simple solution to modify the product_tmpl_id attributes
in other modules.
closesodoo/odoo#97721
Taskid: 2886054
X-original-commit: 312107060f1b6d7aaa907792ee18c9ef22a47cd9
Related: odoo/enterprise#30211
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Have a field with widget text_emojis.
Click Edit on the form view.
Click Save.
Before this commit, the button that opens the dropdown was still present in the dom in readonly mode.
After this commit, it is correctly removed.
closesodoo/odoo#97704
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, If "Show public price & discount to the customer"
discount display policy is selected, taxed prices in the pricelist with
discounts are compared with untaxed prices in the public pricelist,
which leads to not showing the discounted values when the pricelist
value is less than untaxed list price, but the taxed value is more than
untaxed list price.
Steps to reproduce:
1. Create a product, add it to a pricelist with a lower price in a way
that if the tax is added the price is more than its sale price, add a
tax option to the product
2. Set the pricelist discount display policy as `Show public price &
discount to the customer`
3. Set the PoS to use tax-included prices, and to use the discounted
pricelist
4. start the PoS session, add the product, you will see that the
public price isn't shown (with a strike-through)
To fix, we can use a different function that computes the taxed public
price, so it could be compared with the pricelist price.
opw-2919734
closesodoo/odoo#97698
X-original-commit: bbada7911ab59ca20c97fd152112116cab0bf398
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, in a touch device the behaviour was a
"tap-hold-to-show” which let the user see the Tooltip by pressing the
element, and letting it disappear when the pressure ends.
This commit allows choosing between the previous "tap-hold-to-show"
behaviour and a new "tap-to-show" which let the user see the Tooltip by
pressing the element, and keep it open until it press something else.
This behaviour is more adapted when the tooltip is on a specific icon,
as is the case for the labels, since : f981c5f8f0closesodoo/odoo#97680
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a translatable field in a form view.
Create a new record with that form view.
Click on the button to open translations for that field.
Before this commit, the record was not saved before opening the translation dialog, hence
changing the translations could not work properly.
After this commit, this feature is back, and we ask to save a new record before
opening the translation dialog.
closesodoo/odoo#97608
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, images' url where just built upon the record's id and model.
Since the browser caches GET requests by url, the same record would always have the same image url.
Hence it appeared that when changing a record's image in form view, and going back
to the kanban, the image displayed was the old one.
A good enough approximation to solve this (and was actually solved in legacy code), is to use
the record's __last_update field, which basically tells the browser to re-fetch
a record's image when then record go through any modification.
After this commit, images are correctly updated in kanban and form views.
closesodoo/odoo#97544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When a session is opened, the setting that allow using pricelist cannot
be modified, as it can change the prices that should be used, but
existing opened POS will still use the old one.
As the pos settings are now in the res config settings, each time a
setting is changed, all settings are re-written. As the use pricelist
setting is not readonly when a session is open, its value is sent, and
we try two write it (even if value not changed) and it trigger a
constraint saying it cannot be modified.
To avoid such a wrong behavior, we make it readonly when it cannot be
modified.
closesodoo/odoo#97731
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the `BlockUI` component
would not appear when printing a Sales Report
from the PoS backend.
To reproduce, go to PoS:
-> Reporting
-> Sales Details
-> click Print
Issue: The `BlockUI` component should appear on
top of the `Dialog` component, but it doesn't.
The reason for this is because, after some recent changes,
the z-index of 1100 that this component initially had, was
no longer applied, resulting at a lower z-index value for
the `BlockUI`.
In this commit we restore the normal behaviour.
task-2924335
closesodoo/odoo#97730
X-original-commit: 114fbe04eb92248118af46c8cbd137da7233aef9
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the `BlockUI` component from
the web module was not rendered properly.
The reason for this is that after PR #83811 was merged,
the css from `web/static/src/core/ui/block_ui.scss`
was replaced with non-semantic Bootstrap css classes
(e.g. .d-flex, .justify-content-center). Those css
classes were inaccessible to PoS frontend, because
the `point_of_sale` module does not load Bootstrap
code (a design decision).
In this commit, we restore the proper rendering
of the `BlockUI` component both for the "frontend"
of the PoS App.
task-2924335
X-original-commit: 29cbeae90790ff503167b053ec6d9e221a82434e
Part-of: odoo/odoo#97730
The constructor of OdooEditor called a function that initialized the
Powerbox. This moves that function inline into the constructor to avoid
a function called only once, and moves the main commands and categories
directly into the arguments to `new Powerbox()`.
closesodoo/odoo#97725
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The BusService class only adds the possibilty to send notifications.
This is only used in the mail module. Let's remove this unnecessary
override and move this functionnality into mail models.
closesodoo/odoo#97685
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Running tests for `project` module only fails with the following error:
```
2022-08-02 08:19:41,777 5669 ERROR testdb odoo.addons.project.tests.test_project_report: FAIL: TestProjectReport.test_avg_rating_measure
Traceback (most recent call last):
File "/build/odoo/saas-15.3/addons/project/tests/test_project_report.py", line 22, in test_avg_rating_measure
self.assertEqual(self.task_1.rating_last_value, 5.0)
AssertionError: 4.0 != 5.0
```
With the ORM flush mechanisms when multiple ratings are created at once
they all have the same `create_date` and/or `write_date`, this commit
ensure the order is deterministic.
closesodoo/odoo#97691
X-original-commit: 567d27cc600bdbb39d62e7aa75b37d48b33d27a5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The default order of the picking moves generated from a sale order should be the same order as the sale order lines.
Steps to reproduce:
- Create a sale order with several sale lines.
- Change the order of the sale lines.
- Confirm the sale order.
=> The moves of the picking don't maintain same order as set before.
closesodoo/odoo#97690
X-original-commit: 524e5e6bd8feb47256cc0941052d959dd0e0ad0c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In order to perform reverse charge self-invoicing, a company must have
its codice destinario (pa index) defined. This commit adds a valid
pa_index (from the sdicoop test channel) to the demo company.
closesodoo/odoo#97658
X-original-commit: 42c08b298dba5d4e34ed10ae4fd8828db9636a8a
Signed-off-by: Josse Colpaert <jco@odoo.com>
For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
It is not possible to process an invoice and send it to the SII
Steps to reproduce:
1. Install l10n_es_edi_sii module
2. Switch to company 'ES Company'
3. Go to Settings > Invoicing > Spain Localization > Registro de Libros
connection SII and select 'Hacienda Foral de Gipuzkoa'
4. Go to Invoicing > Configuration > Accounting > Journals and open
'Customer Invoices'. In the 'Advanced Settings' tab, enable EDI
functionality 'SII IVA Llevanza de libros registro (ES)'
5. Go to Invoicing > Configuration > Spain > Certificate (ES) and import
the certificate (file named sello_entidad_act.p12 in
l10n_es_edi_sii/demo/certificates/) with password "IZDesa2021"
6. Create an invoice with any customer and product and confirm it
7. Click on 'Process now', an error is raised
Solution:
Use PyOpenSSL to be able to use certificate checking
Problem:
With the version of requests specified in the requirements, SSLContext
object doesn't have a `_ctx` attribute anymore. That's because PyOpenSSL
is not used by default (https://pyup.io/changelogs/requests/#2.24.0) and
ssl is used instead. However we need PyOpenSSL to be able to use
certificate checking (https://urllib3.readthedocs.io/en/latest/reference/contrib/pyopenssl.html)
opw-2925510
closesodoo/odoo#97655
X-original-commit: 1d76ab521ab7d457c6881181bdde557f520fd78e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, it was possible to make the JS crash due to maximum
call stack reached due to some recursion between 2 field visibility.
It was then preventing the page to even be accessed as it is the 000.js
(public file) which is failing.
The only way to fix that is then to go through the backend.
Step to reproduce:
- Enter edit mode and drag & drop a form snippet on the page
- Select a field, let's call it field_a
- Set its visibility option in the right panel to "Visible only if" and
select another field as value, let's call it field_b
- Now select field_b and do the same operation and set field_a as value
- Save
After save, the 000.js file will be executed and the traceback will
occur, preventing the page to work at all.
Note that the illustrated example is about direct and obvious circular
dependency, but it could also be about indirect circular dependency like
field_a depends of field_b, field_b depends of field_c and field_c
depends of field_a.
opw-2889860
closesodoo/odoo#97652
X-original-commit: 90ecfab61f0c71850c1f3bc3ab2644883d18f9a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
How to reproduce the bug ?
- install point_of_sale,l10n_mx_edi
- In Point of Sale > Settings, add at least one Payment Methods
- Still in Point of Sale > Settings, create one Point of Sale
- In Point of Sale > Products > Products, select one product.
- In the Accounting tab of the product, set the UNSPSC Category.
- Go back on the dashboard of Point of Sale and start a new session.
- Add the product you have selected before and go to calidate the
invoice.
- Pick a payment methode and a costumer and check the invoice option.
- Validate the invoice.
- Close the session and go to Point of Sale > Orders > Orders.
- Click on the order you have just created and click on Invoice (in the
top right corner).
- Reset the invoice in draft.
- Wait for the cron task to be executed or execute it manually.
What is the bug ?
The cron task that send all the edi documents doesn't consider the state
of the account_move linked to it. Because of that if an invoice poster
is reset to draft, it will have a document and this document will be
sent.
opw-2925137
closesodoo/odoo#97648
X-original-commit: b27ff3c3c610102b2254acbad3801f21f0b36ef3
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
The domain "id = False" for the visibility of the "Split Expense"
was set because I (wrongfully) thought it was necessary to save
the record before the wizard could use it.
That is not the case, as the button call will first save the record
anyway - it was weird not to have this button immediately and made
the feature hard to discover.
I also changed the "create report" button for the same reason - there
is no need to restrict its usage to "saved" records (unlike the
"attach receipt" button which is a specific widget that needs the record
to exist in database to work).
closesodoo/odoo#97634
Signed-off-by: Kevin Baptiste <kba@odoo.com>
According to
www.agenziaentrate.gov.it/portale/web/guest/schede/istanze/richiesta-ts_cf/informazioni-codificazione-pf
The tax identification number of natural persons
consists of an alphanumeric expression of sixteen characters.
The first fifteen characters are indicative of the master data
of each individual in the following order:
- 3 alphabetic characters for the surname;
- 3 alphabetic characters for the first name;
- 2 numeric characters for the year of birth;
- 1 alphabetic character for the month of birth;
- 2 numeric characters for the day of birth and sex;
- 4 characters, 1 alphabetic and 3 numeric for the Italian municipality
or foreign state of birth.
The sixteenth character, alphabetic, serves as a control.
The main fix is about this part:
When two or more individuals have master data generating
the same tax code (homocodes), the tax code is differentiated
for each of them. For this purpose, systematic substitutions
of one or more digits starting from the right one are made
within the seven numeric characters contained in the code
with corresponding alphabetic characters according to the
following table:
0 = L 4 = Q 8 = U
1 = M 5 = R 9 = V
2 = N 6 = S
3 = P 7 = T
Also the check for iva number format was incomplete.
Indeed, The three penultimate digits correspond to the region of the
VAT office and must be between 001 and 100 inclusive,
or equal to 120, 121, 888 or 999.
We use the stdnum library's methods for the validation of fiscal code
and iva number format.
opw-2797408
closesodoo/odoo#97633
X-original-commit: 262eb7bd021d177d9a05397f9cda3fc76a21d4cb
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
1. Add a few products to your cart.
2. Go to the checkout page, and stop right before clicking on 'Pay now'
(ie: customer goes to find the credit card and comes back later)
3. On another tab, go to the backend and cancel the sale.order
4. Go back to the website tab, and click on Pay now
5. Complete the payment process
Result:
* The customer is able to pay a cancelled order.
Expected:
* It shouldn't be possible to click on 'Pay now'
closes odoo/odoo#97630
Forward-port-of: #96549
X-original-commit: 37c3cf55d507e0bccf9db3e63503dfec896dfaef
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, milestone is still visible in project burger
menu even if we disable the milestone feature and due to that while
creating the milestone it was generating the traceback.
So in this commit, add groups on milestone option on project burger menu.
task-2918411
closesodoo/odoo#97629
X-original-commit: 1a7e2a298c2cbf076ce96dae85805f9dd77c7e0d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When issuing a refund for a reverse charge bill, the document type
should be the same as the parent bill type (either TD16, TD17 or TD18,
rather than TD04), and the values of the lines and totals should be
negative.
To fix this the values are made negative dependent upon whether the
invoice is a 'rc_refund' as in a "reverse charge refund". The way that
the document type is ascertained is also changed in order to include the
'in_refund' (for the case of the reverse charge refund).
The way document_total (ImportoTotaleDocumento) has been made
conditionally negative in the case when the invoice is a reverse charge
refund.
A test has been added for the reverse charge refund case, and the test
taxes have been adapted so that the correct tags are being used (and so
that tags are used on the refund lines).
closesodoo/odoo#97619
Ticket-id: 2936967
X-original-commit: ca2f4c8e1babe9444bc2c6a7421eafb63f1c9346
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Before this commit, opening a misc journal entry resulted in an error because we tried
to compute the tax totals as if it was an invoice.
This commit ignores the computation of these tax totals in case we have a misc journaly entry.
opw-2946634
closesodoo/odoo#97600
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- With a vendor
- Routes: Buy
4. Add a reordering rule to P:
- Min = Max = 0
5. Create and confirm a planned delivery order with 5 x P
6. Run the scheduler, it should create:
- An internal transfer IT (Input -> Stock) with one stock move SM
- A purchase order PO
7. Edit PO:
- 4 x P (instead of 5)
8. Confirm PO
9. List all transfers related to P
Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM
As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From | To | Dest |
|------|-----|---------|-------|------|
| SM01 | 5 | Input | Stock | / |
| SM02 | 5 | Vendors | Input | SM01 |
| SM03 | -1 | Vendors | Input | SM04 |
| SM04 | -1 | Input | Stock | / |
Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.
Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.
When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523
And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.
OPW-2861605
closesodoo/odoo#97599
X-original-commit: 43ca47cdfec696b847f716984f76df16de7b97b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Open Online Appointment in list view
=> a "double-border" is visible above the optional columns button
closesodoo/odoo#97592
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, modifiers containing conditions on the `id`
field weren't always correctly evaluated in form views. This
happened on new records, when the `id` field wasn't present in
the view. In this case, its value in the evalContext was
`undefined`, so a domain like `("id", "!=", "False")` was always
evaluated to true. The `id` field is handled a bit differently
than the other ones, as we do not require for the field to be
present to use it in modifiers (mostly because we don't need it
to be present to know its value).
This commit fixes the issue by forcing a `false` value for `id`
when the record has no id yet.
closesodoo/odoo#97587
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
odoo/odoo#87678 redesigned part of the search_panel however one of the
old bootstrap calsses was still used which resulted in sub categories
rendering poorly.
This commit changes that class to the new name.
closesodoo/odoo#97585
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Aurélien Warnon