Steps to produce:
- Configure Google Calendar and navigate to the calendar app.
- Click on the Google sync button, redirecting to the general settings.
Before this commit, the Google sync pause buttons directed users to the general
settings.
with this commit, it now redirects to the calendar settings.
task-3731652
Part-of: odoo/odoo#153581
Remove `No documents to display` as there will always be aa least
the addresses and security/connection cards.
closesodoo/odoo#146197
Task-id: 3629038
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
"Mandatory" days use a random text color and they don't render well with
the colored background colors of `.fc-today` and hovered days.
The text-color has been removed on hovered mandatory days and
mandatory days happening "today".
The background of "fc-today" now uses the color of mandatory days when
that day is mandatory.
The SCSS has been cleaned up so as to not create repetitions.
task-3617334
part of task-3575827
closesodoo/odoo#144236
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When a payment method was updated in a way that prevented creating
tokens with it, that is, by either disabling it, unchecking the
"Tokenization Supported" field, or unlinking it from providers, only the
latter would automatically archive the related tokens after showing a
warning to the user. The two first actions prevented the creation of
future tokens with that payment method, but existing tokens could still
be used.
This commit fixes that behavior by adding the warning and the automatic
archiving of related tokens where they were missing. Preventing further
tokenization with a payment method now consistently blocks payments
through existing tokens, too.
closesodoo/odoo#150120
Related: odoo/enterprise#54700
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
The keyword arguments of the callees were never forwarded to the
`payment.method::_get_compatible_payment_methods` method, preventing
overriding modules from controlling which payment method should be
available depending on the kwargs.
task-3640488
Part-of: odoo/odoo#150120
Issue:
- when an order is created through the kiosk, the order appears several
times on the cashiers side.
Steps to Reproduce:
- Make an order in the POS kiosk.
- In the backend, navigate to the kiosk's session and select
"Continue Selling."
- Click on "Orders" located on the top right.
- Observe that the order appears multiple times on the cashier's side.
Solution:
- added _get_shared_orders that retrieve orders without duplicates.
opw-3597973
closesodoo/odoo#149049
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Testing quantities and availablility states in subcontracted BoM report
1. Create a BoM of a finished product with a single component
2. Update the on hand quantity of BoM to 100
3. Move 20 components to subcontracting location
4. Check that the free/on-hand quantity of component is 100 (sum of warehouse stock and subcontracting location stock)
5. Check that producible quantity of 'Product' is equal to only subcontractor location stock
6. Check availability states when:
6a. Search quantity <= subcontractor quantity: component is available
6b. Subcontractor quantity <= search quantity <= total quantity: component is available
6c. Total quantity < search quantity: component is unavailable
task-3632211
closesodoo/odoo#145889
Signed-off-by: Steve Van Essche <svs@odoo.com>
The free to produce quantity was calculated based on the available stock in the warehouse in addition to the subcontracting location. For this reason, `free_to_manufacture_qty` variable was introduced. If it is a non-subcontracting BoM, it will be equal to the free quantity available in warehouse stock. Otherwise, it will contain only the stock in the subcontracting location.
task-3632211
Part-of: odoo/odoo#145889
When `_update_product_info` and `_get_components_closest_forecasted` were called on bom lines or child components, the functions were called with a parent product equal to the parent of the current product, whereas it should be called with the current product itself as we are calling functions recursively in a DFS-like pattern.
task-3632211
Part-of: odoo/odoo#145889
In BoM overview report, the free quantity and the on hand quantity only reflected the available stock in subcontracting location. After this commit, selected warehouse stock is also included in the calculation.
task-3632211
Part-of: odoo/odoo#145889
If user created pricelist which applied discount on fixed prize delivery
and set the discount visibilty to be shown in sale order, the discount
would be applied twice. Due to stable version limitation, the visibility
of discount on sale order for pricelist discount for delivery is removed.
opw-3517879
closesodoo/odoo#154663
X-original-commit: f96ce5102aea5651710bb5bf50903b1c1d4f101e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
In cases where the cursor is at the end of the current block and the next block
begins with a zero-width space, the mechanism that skips these characters while
using arrow keys should not traverse all the way to the end of the zero-width
space in the next block. Because this mechanism operates before the browser
applies its own behavior for arrow keys, potentially causing the cursor to jump
to the start of the third block when second block only contains a zero-width
space, completely bypassing the second block. Conversely true for the arrow left
keys.
This commit ensures that the navigation does not extend beyond the current block
when searching for a `newFocusNode` when moving with arrow keys near zero-width
space.
task-3653307
closesodoo/odoo#154676
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
- Install Accounting and Purchase
- Create a PO with Purchase Representative different from current user
(e.g. Marc Demo)
1) - Mark the product as received
- Create a bill from PO
2) - Go to Accounting
- Create a bill
- Select the PO in Auto-Complete field
- Save the bill
Issue:
The Purchase Representative of the PO is set as Salesperson (hidden field) of the bill.
He should not.
In the second case, by adding the purchase representative as Salesperson of the bill,
he is also added as a follower of the bill and he receives a notification about being
assigned to the bill.
opw-3677713
closesodoo/odoo#154669
X-original-commit: 07cf6c0e320cd719ea5b6531c2c84f55d8627722
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
When a tax is set to inactive, the fiscal positions mapping other taxes to it continued to apply, disregarding the fact that it shouldn't be used anymore. Not anymore with this fix.
closesodoo/odoo#154646
X-original-commit: 07fa1b880875fc075555ca65f4ddd0cddb619979
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Go to Documents activity view.
- Click on Schedule activity.
- Perform multiple clicks on any record.
Issue:
The 'Schedule Activity' wizard opened as many times as the record was clicked.
As a result, even after successfully scheduling an activity on that record,
the user still faced multiple open wizards remaining and had to manually close
each one of them.
Fix:
This commit introduces a method `executeOnceAndClose` which makes use of a
flag 'busy' to ensure that the `onSelected` function is called only once and
hence exactly one `Schedule Activity` wizard is opened, despite clicking a record
more than once.
closesodoo/odoo#154442
Task: 3721404
X-original-commit: 19cc5ea3cf2c8fcf742ba5ab9b4b82305d81d555
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open Settings/Gamification Tools/Challenges
- Create a new challenge
- Keep "Assign Challenge to" with default values
- Need a domain that return some user
- Create and Edit a goal
- Computation Mode: "Automatic: sum on a field"
- Save & Close
- In reward Tab set "For Every Succeeding User"
- Save
- Start Challenge
Actual result:
- Traceback due to wrong aggregate value
- CHallenge is not started
Expected result:
- Challenge is started
opw-3740960
odoo/odoo@234db70dclosesodoo/odoo#154614
X-original-commit: aa0f617682a59c5ac285308000f35d44b75f04df
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Previously, an issue was observed where the dropdown menu of the
spreadsheet's share button displayed a scroll bar when users had
selected a different language, such as French (BE).
This commit addresses the problem by setting the height of the dropdown
menu to auto, thereby resolving the issue of unnecessary scroll bar.
Task ID: 3742260
closesodoo/odoo#154561
X-original-commit: a3b56d25357ed7e7cadbf5f955440b2c2c4d7a35
Signed-off-by: Adrien Minne (adrm) <adrm@odoo.com>
Current behavior:
Creating an SO with negative quantities for a storable product with an
invoicing policy of type "delivered quantities" automatically generates
a return move for the stocks. However, when this delivery is validated,
the delivered quantities are not updated on the SO. This is problematic
as these quantities are therefore not taken into account on the
associated invoice.
Expected behavior:
The delivered quantities should be updated negatively on the SO to
enable the invoicing of these lines.
This is already the behavior in the POS application and when you
create an SO with positive quantities followed by a return
for a larger quantity than the one delivered.
Steps to reproduce:
Create a storable product with an invoicing policy of type "delivered
quantities".
Create an SO with 2 lines:
- a line with positive quantities for any other product.
- a line with negative quantities for the product you created.
Confirm and validate the corresponding deliveries.
Return to the SO. The quantities for the second line are not updated.
Create an invoice. The second line is not taken into account.
Cause of the issue:
The to_refund field of the stock.move model defined in the stock_account
module enables a decrease of the delivered quantities in the associated
Sale Order. This field is set to True for "classic" returns but not for
the stock.move generated from sale.order.line with negative quantities.
Fix:
We rely on the _get_custom_move_fields method to add the to_refund
field in the procurement 'values' arguments in case the stock_account
module is not installed. It is then available to use in the
_get_stock_move_values method where we set its value to True if the
quantity is negative (so that the move should be considered as a refund)
opw-3676045
closesodoo/odoo#154496
X-original-commit: 92917d507a63ee08fc839ed3f7607d5e5060f0a2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
How to reproduce:
1. Open eLearning app
2. Go to any course having document with quiz.
3. Solve the quiz
4. Click multiple time quickly on 'Done' (green tick) button.
5. Multiple quiz are displayed if your connection is slow or you click fast
enough.
The fix ensures that only one quiz is displayed. We do the same change for
video to prevent such problem with them.
Technical note: when clicking on the "green tick" of the quiz, the method
_toggleSlideCompleted is called which cause a _renderSlide. That method clears
the content div (o_wslides_fs_content) and appends a new Quiz widget to that
div. The problem is that the "append" is asynchronous (it call the "willStart"
of Quiz widget that fetch the quiz) so if you click multiple time, the content
div is cleared multiple times and then after each quiz created is ready (after
having fetched the data), they are appended to the content div, resulting in
multiple quiz displayed.
We solve the problem by avoiding concurrent execution of the _renderSlide
method: the body of the method is skipped when the rendering is ongoing (for
example while waiting the quiz from the server). As the method is inserting the
slide at the same place, its behavior was anyway unpredictable because
depending on the response time of each request. By skipping the method body
while already running we make it a bit more predictable, avoid the content
duplication on the page, and we avoid unnecessary call to the server.
Task-3412847
closesodoo/odoo#154069
X-original-commit: 72e035274de3bbf7fcc858008bc00d095163e7f3
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Pierre-Yves Dufays (pydu) <pydu@odoo.com>
This will add options for month, quarters and year selection to the start and end dates filters.
closesodoo/odoo#154577
Task: 3725209
X-original-commit: ac21aa953b19ba2e7bdb33b52a2616a50362d2e6
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
**Current behavior:**
Enabling the 'Comparison Price' setting and filling out the
field will result in this strikethrough price appearing even
after disabling the setting.
**Expected behavior:**
The strikethrough comparison price will only appear when the
corresponding setting is enabled in the database settings.
**Steps to reproduce:**
1. Enable the 'Comparison Price' setting in website settings
2. Select a product on the 'Shop' page of the website and edit
it so it has a comparison price != to its regular one
3. Save product changes, go back to the db settings and disable
the 'Comparison Price' setting
4. Go back to the website 'Shop' page and observe that the
strikethrough comparison price is still displayed
**Cause of the issue:**
In the product.template model in website_sale, the price values
are modified to those informed by the compare_list_price value
independent of the current value of the corresponding database
setting. It only checks if there is non-False value in the
field.
**Fix:**
Check if the user belongs to the group corresponding to this db
settings prior to modifying the product template to display the
strikethrough compare price.
opw-3705079
closesodoo/odoo#154573
X-original-commit: 0d76bdb23d26f777587c9c30d5479fdf3c694937
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, highlighting several days
from the calendar view in Time Off would still take the
first day selected as the default date_to.
The expected behaviour is that it should be the last
day highlighted instead.
closesodoo/odoo#154469
X-original-commit: fcd2b141a337913e376f7ce0d2b313b68d97d6cc
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
This commit fixes a pretty specific issue within autocomplete behavior
where the change event after clearing the value is prevented.
Steps to reproduce:
- go to an empty autocomplete and click on it
- start typing a search with results
- click on the first result
- without focusing out, clear the input and finally click out
No change event is triggered on click out in this case so the cleared
value is not updated in the end and saving the record will keep the
non cleared value.
The t-on-mousedown.prevent in the dropdown was mainly used to keep the
focus on the input after selecting a value for the autocomplete. This
introduces a side effect: when one starts typing on the initially empty
autocomplete, the browser keeps the initial value of the input in memory
until it is focused out (and therefore blurred). When the input is
focused out, it will compare the current value of the input with the
stored initial value and decide to trigger a change event based on the
comparison between the two values: if these are different, the change
will trigger. In our case, since the mousedown event on a search result
is prevented, no focus out will happen and therefore the browser will
still wait for the next focus out to trigger the eventual change event.
But since we clear the input before focusing out, the two values are
empty and no change event is triggered which introduces the issue.
To fix it, we remove the t-on-mousedown.prevent of the template and
manually avoid triggering the onInputBlur method with a flag to keep
the previous behavior and we finally focus on the input programatically
after selecting a value.
task-3734818
closesodoo/odoo#154448
X-original-commit: 9d3d5d937e37ab6ef0c393e11cfb449f2897f6c1
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Before this commit, users could create a refund order from multiple
invoiced orders. However, such an order could not be invoiced as it was
associated with more than one account_move, leading to a failure. This
commit fixes this issue by preventing users from creating a refund
order from multiple invoiced orders.
opw-3710539
closesodoo/odoo#154369
X-original-commit: 177b0378d046ac769f2349c6444d14ca280e3c77
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Updates to existing product configurations with custom attributes
were not correctly applied on configurator closure.
This was probably caused by a recent update in the framework.
Nevertheless, to solve the problem, this commit drops the use
of custom code used only by the configurator to stick to the
standard usage of magic commands.
closesodoo/odoo#152934
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The homeworking popover was not working with the `#scheduling_box` on
mobile, the latter covering the buttons of the popover.
To solve this, we replace the popover by a dialog on mobile.
task-3630139
part of task-3575827
closesodoo/odoo#145446
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Issue:
When trying to create a lead for a partner that has no email. It raises an error that the email is null.
This happens because the code expects 'emails' to contain email_from, even though it could just be email_cc in there.
Steps to reproduce:
1- Install CRM app.
2- Enable leads in CRM settings
3- In sales menue choose customers
4- Create a new customer without providing an email
5- Choose Leads
6- Create a new lead using the newely created customer
7- You get "AttributeError: 'bool' object has no attribute 'lower'" in line: https://github.com/odoo/odoo/blob/8e17a4d76bbdd547536e62ee12a2c514a16d1700/addons/crm/models/crm_lead.py#L1873
Solution:
The main issue is the code relies on the email to provide a name for the lead, so we need to check if there's an email provided beforehand
opw-3681485
closesodoo/odoo#154483
X-original-commit: 96f08b00afdb1b1d042a98649a10f776fb9439c9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Omar Abosamaha (abom) <abom@odoo.com>
1. set a country like belgium
2. set a VAT number like BE123456789 => peppol_endpoint is not computed
This is because some dependencies are missing on the field (current is: "country_code").
Step 1: Add the missing dependencies to the field (and improve the tests to make sure it works).
Step 2: Try to make the code smarter! If the country_code is BE but the VAT number starts with FR,
consider it's FR, not BE. If the codice_fiscale is set, it's IT whatever the country_code.
If the VAT number has no ISO country code, use the country_code in that case.
task-3690913
closesodoo/odoo#154375
X-original-commit: 46d2bf0dd08b1a925ad51c91aa37024cd5a6ee16
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Description of the issue/feature this PR addresses:
Depending on user rights or customization, "Print" or "Action" menu can equals to "undefined". This causes a client error when selecting lines in the tree view.
Current behavior before PR:
javascript error " TypeError: print/action is undefined" is raised when selecting lines in the inventory list tree view.
Desired behavior after PR is merged:
No error raised if user has no print/action menu available.
closesodoo/odoo#154254
X-original-commit: d2df56d1fadf3a83f1096405847dca0a79b474db
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, an Odoo dialog would open to show errors that
occurred in the pages embedding the live chat. We should not display
errors originating from outside the embedded script. Moreover, the
error service listens to the error event on the window object. Thus,
errors occurring in the shadow DOM won't be caught. As a result, the
error service disrupts the site that embeds it and is entirely useless
for the live chat.
This PR removes the error service from the embedded live chat.
OPW-3699040
closesodoo/odoo#154102
X-original-commit: 24b6b7a43748b5f1053aa7c70dc7046dbc894c7f
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The xpath used in the res_partner_view replaces the vat field with
a div, containing the partner vat and the VIES valid field (such that
they are displayed on a single row). This results in the
partner-autocomplete being removed from the field.
The solution is to make a div, and a subsequent xpath that moves the
"vat" field into this div (alongside the vies valid field). This no
longer overrides the partner-autocomplete xpath.
closesodoo/odoo#154506
Task-id: none
X-original-commit: ffc8441b4ba09e3d10f15425c32f8fdb3fb7d863
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Co-authored-by: aliya <alta@odoo.com>
Since commit [1], there is no outline when focusing a hoverable dropdown
by using the Tab key. This happens because of a CSS rule that was added
so no outline would appear when hovering the dropdown menus with the
mouse. However, it should still be displayed when using the keyboard,
for accessibility reasons.
This commit fixes that by always allowing the focus on the hoverable
dropdowns, except when they are hovered. If a focus was present on an
element in the document when hovering, its focus is kept (to have the
same behavior as in previous versions).
Steps to reproduce:
- Add a submenu and a mega menu with the menu editor.
- In edit mode, set the dropdowns as hoverable (set the "Sub Menus"
option to "On Hover") and save.
- Use the Tab key to navigate through the menus.
=> The simple menus have an outline but this is not the case for the
dropdowns.
[1]: https://github.com/odoo/odoo/commit/5846a05fe7bf587d3bfb3ace3e863cb4abd52132
task-3709755
closesodoo/odoo#154505
X-original-commit: a8b3e589cd7e6c9ecfd33ba4ae9883e7ade2e599
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
action_set_supplier doesn't have to overwrite the orderpoint.route_id if it already has one that fit the requirements (action = 'buy').
OPW-3746624
closesodoo/odoo#154495
X-original-commit: f52a17082a5507b283a0107118ef411d3be0b192
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue:
=====
Undo of resize operation on table do 2 undos in a row.
Steps to reproduce the issue:
=============================
- Go to website editor
- Add a text block
- write `/table` to insert a table
- Resize the table
- Press `ctr+z` to undo
- The table is removed
Origin of the issue:
====================
The resize operation wasn't saved a step and is considered as draft
then it will be discarded and then the undo applied on the last saved
step that's why it appears as 2 undo in a row.
Solution:
=========
Call `historyStep` when we stop resizing.
task-3743697
closesodoo/odoo#154402
X-original-commit: 836a68e29c8fa881854b19c7489086537127d4a3
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
We no longer round the PriceAmount since
0fd7284158483bce3308e7c5ba42e3c6ee5abd10.
But then, we may encounter a representation error if the PriceAmount is
not exactly representable as a binary fraction (see:
https://docs.python.org/3/tutorial/floatingpoint.html#representation-error).
For instance: having a line with `price_subtotal` = 306.45 and
`quantity` = 3, we will compute the PriceAmount as 306.45 / 3 which
yields 102.14999999999999.
To avoid such a case we round "reasonably" the PriceAmount.
opw-3729369
closesodoo/odoo#154361
X-original-commit: f27818e7bc62c548e9bd76d47594d3dcdec85d3d
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
This commit excludes delivery programs from being counted
towards rewards for loyalty programs.
Prior to this commit, there was an issue steaming from the Standard Delivery
line being added to the Sales Order during the transition from the
"Review Order" screen to the "Confirm Order" screen. This flow illustrated
that loyalty programs count delivery line toward rewards for loyalty
programs.
[Reproduce]
- Install Odoo with modules: sale_loyalty,website_sale,delivery
- Create a loyalty program:
- Enable "Discounts, Loyalty & Gift Card."
- Archive all the programs.
- Create a program with type "Promotions."
- Set program conditions:
- Minimum Quantity: 2
- Minimum Purchase: 0
- Grant 1 point per order
- Among Product Domain "Match all records."
- Set program Rewards:
- Type: Discount
- In exchange for 1 promo point.
- Navigate to the front-end shop:
- Select 1 item.
- Add it to the cart.
- Proceed to Checkout.
- Ensure there is one item (you need 2 for the discount).
- "Proceed to Checkout" (delivery is added to the Sales Order at this point).
- Click "Review Order" to go back.
- BUG: The discount is shown in the "Review Order" screen.
opw-3675387
closesodoo/odoo#153905
X-original-commit: cf513b0bcb61ca3862ab20c12c26b12efe590ab7
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce:
1. Type a backtick
2. Type "A"
3. Type a backtick
4. Hit Left Arrow key
5. Hit Right Arrow key 2x
This led to a traceback ("Cannot read properties of null (reading
'isContentEditable') at OdooEditor._onKeyDown") because using `nextLeaf`
without specifying the editable bounds returned a node that was not
within these bounds, and a subsequent call to `closestElement` on this
node returned `null` as a result.
task-3749506
closesodoo/odoo#154484
X-original-commit: ec1fe7b05e0d91605f78dd1844c7d2222671eab3
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce
==================
1. Visit the website and open the event tab.
2. Access an event with the talks and exhibitor sub-menu.
3. Select the talks sub-menu and search for a talk
-> Even if the talk exists, the search count shows zero
-> The same thing happens in the exhibitor sub-menu
Technical
==========
When searching for the talk or the exhibitor we didn't send the search_count due
to this, it is always showing zero.
A variable sponsor is renamed to sorted_sponsors as it was redeclared in the
loop before the return dict.
After this commit
=================
Now the search_count will display the accurate result.
Task-3659940
closesodoo/odoo#154438
X-original-commit: 2a6d479f1b8c0d7cad40e6c2a3fc2f5d7d75bfad
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Shaan Thakkar (thsh) <thsh@odoo.com>
Before this commit, if the search result would have "load more", the
extra messages would immediately be fetched, defeating the purpose to
have load more in the first place, and making unnecessary requests.
closesodoo/odoo#154406
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes an issue where free products associated with a tag
were not being added to the order. The logic for adding free products
based on tags has been corrected to ensure proper functionality.
opw-3702040
closesodoo/odoo#154360
X-original-commit: defd5ef63b83f92f26be11d2f62b25f0f4c671a3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
**Current behavior:**
Creating a new company and trying to switch to the l10n_ee
accounting localization package will result in a validation
error, preventing the installation.
**Expected behavior:**
The package should be installed and automatically activated for
the active company.
**Steps to reproduce:**
0. Install the l10n_ee accounting module
1. Create a new company such that no fiscal localization
package is active by default, then switch to this new
company in the selection in the top right
2. In Accounting settings, select the Estonia fiscal
localization package and save (this causes the exception)
**Cause of the issue:**
Certain tax accounts in the module do not have their names
fully updated. They all were labeled as "0% ..." instead of
their true percentages like all other tax accounts.
**Fix:**
Update the names of the offending tax accounts so that they are
fully reflective of their true %.
opw-3683538
closesodoo/odoo#154169
X-original-commit: 33d880cc733b90903e2facd21c134dbdc2e58de1
Related: odoo/enterprise#56693
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Steps to reproduce:
1- Install Field Service module
2- Create new task and click on products smart button
3- Hover over a product and click on the dropdown menu
4- Click on edit in the dropdown menu
5- Get back to the products page and check the quantity for the product you edited
Current behavior before PR:
When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated.
Desired behavior after PR is merged:
This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity.
opw-3689864
closesodoo/odoo#153293
Related: odoo/enterprise#56161
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
If product has no_variant attributes with 2 values and the first value was deleted,
it is still returning it in the product configurator.
Filter the template's value ids to return only active variants
opw-3570604
closesodoo/odoo#154278
X-original-commit: df15b25e8e36fdfde7644fc183daf1da7d9485c1
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Signed-off-by: Lina Eweis (liew) <liew@odoo.com>
Commit [1] added a rule whose intention was to unify the way our editor
labels look: capitalized. However, this is not working as intended for
translations as some languages have different rules for capitalization.
In the future, we will rely solely on the labels being written with the
intended capitalization in the first place (which is currently not the
case for dozens of English labels). As a fix, we keep the auto CSS rule
for English languages only. Hopefully, the amount of translations made
by translators being better than their auto-capitalized versions is
greater than non-capitalized English labels translated by mistake
without the auto-capitalization.
Note: this is the way python fields work too, they are not displayed
auto-capitalized in the webclient, although we want them to be.
[1]: https://github.com/odoo/odoo/commit/5db73c12d3ed14239dc81f60eec6c21d0f65af26closesodoo/odoo#153732
X-original-commit: 453b1e86840d81ffeff4d182b161b0ea50a38486
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Gurpreet Singh