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>
Correct/improve the view of the point of sale configuration
by hiding certain unnecessary parts for certain user groups.
closesodoo/odoo#154359
X-original-commit: 1a2009387756f5bf41ed3c7a3ec3a892a1e4336a
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Make the set() of module sorted, aka a list.
We can be pretty sure that nobody relied on the order of this set before
since it was completely underterministic. Therefor this change should
not break anything and make the testing on runbot more consistant.
This is mainly following the issue with the sql-injection testing
failing randomly with the order of the modules.
closesodoo/odoo#154324
X-original-commit: bbe33a1260ab3bfe97caa1197adbf00c661ddfb4
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Since 4da8c6ebca, the lot creation when filling a stock move line is
done via the stock quant "pick from" field. We thus don't have the
'active_picking_id' key that was set on lot_id field to check if the
user can create or not new stock lot for a particular picking.
This commit add this context key back on the stock move line one2many
for it to be available at the stock quant creation.
closesodoo/odoo#152915
Task: 3670447
X-original-commit: ce4f6f668cf8308b4b9af14ffc74f0df6428a771
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
- set a leave type and an accrual plan based on hours
- create a new accrual allocation on those leave type and accrual
- change the date_from so that some hours are accrued
- set a custom amount
- save or validate
- the value should fall back on the initial amount
This fix should allow to keep the custom amount set by the user.
task-3615695
closesodoo/odoo#144306
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This commit follows [1], which attempted to fix CORS errors
occurring when we access the `cssRules` property of stylesheets,
to detect scss compilation errors and display a warning to the
user.
[1] doesn't seem to be enough, as we faced another source of CORS
errors. Indeed, in non-secure http, the error is raised even if the
origin is the same.
We never want this access to crash anyway, as it's a nice to have
feature, and if reading `cssRules` is forbidden, there's nothing
the user can do anyway. For those reasons, we decided to simply
protect the code with a try/catch.
[1] odoo/odoo#152696
opw 3746910
closesodoo/odoo#154347
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce issue:
1. Select a Contact
2. Click on Smart Button "Loyalty Cards"
3. Create a new Loyalty Coupon
4. Save
5. Receive an error:
> The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.
>
> Model: Loyalty Coupon (loyalty.card)
> Constraint: loyalty_card_program_id_fkey
Explanation:
The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the case of the issue, for example, the model is `res.partner`.
https://github.com/odoo/odoo/blob/a3201d636505dc1976d3f0ee7f8cbf65d2488966/addons/loyalty/models/loyalty_card.py#L27
Suggested fix:
The creation of `loyalty.card` from `res.partner` Smart Button is not intended, therefore we will remove this option and set the Smart Button as invisible if `loyalty_card_count` is null.
opw-3707588
closesodoo/odoo#154258
X-original-commit: 8645874ec0e7ae81f032231be4908e173d2a4043
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
This commit addresses an issue introduced after the Analytic
distributions changes in v17 where printing expense reports with
cross-analytic distribution raises a traceback.
Given that analytic distributions offer limited value on printed expense
reports and considering that no other printed reports in Odoo currently
display the analytic distribution, they have been removed.
task-3722135
closesodoo/odoo#153569
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Current behaviour before commit:
In v17.0 and above trying to open emoji-picker
throws traceback. This happens because not able
to find input element inside onPositioned method.
Desired behaviour after commit:
Now there is no traceback when opening emoji-picker.
task-3729610
closesodoo/odoo#153186
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode)
and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs').
'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10.
task-3626894
closesodoo/odoo#151314
Related: odoo/enterprise#55218
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit
===============
Global discount with Tax effect been developed in such a way that it calculates
discount based on tax groups and brings correct tax liabilities to comply.
Where in it drops lines with minus in invoice form, While doing E Invoice in
India - Government portal not entertain product with minus lines to reduce
liability.
After this commit
===============
Refactored invoice form for E-Invoice in India post-global discount
implementation. Adjusted discount sign to address the government portal's
restriction on negative lines. The fix ensures the portal now accepts discount
lines, aligning with regulatory requirements.
closesodoo/odoo#146163
Task: 3454674
Signed-off-by: Josse Colpaert <jco@odoo.com>
Ensure the country is set on the customer and supplier for Peppol Bis 3
to avoid errors like "[BR-11]-The Buyer postal address shall contain a
Buyer country code (BT-55). [BR-57]-Each Deliver to address (BG-15)
shall contain a Deliver to country code (BT-80). [BR-09]-The Seller
postal address (BG-5) shall contain a Seller country code (BT-40)."
closesodoo/odoo#154233
X-original-commit: 8a764c82816bf55d8bdf44a38b8b69998f6acb4b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be
prefixed with a 2 letters code representing the country of the partner.
Currently, filling a VAT without this country code will lead to the
error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax
representative VAT identifier (BT-63) and the Buyer VAT identifier
(BT-48) shall have a prefix in accordance with ISO code ISO 3166-1
alpha-2 by which the country of issue may be identified. Nevertheless,
Greece may use the prefix ‘EL’."
On the other hand, some extra-european countries use Peppol Bis 3 but do
not prepend their VAT with the country code (i.e. Australia). To allow
such cases, we automatically add the country code when it's missing.
To prevent regression, we also add a contraint mimicking the schematron:
we check that the final value of the PartyTaxScheme/CompanyID is
prefixed with a 2 letters code. This way, the constraint is independant
from the code.
X-original-commit: b1ab100046db4ee65bed482c1abbf951190f8921
Part-of: odoo/odoo#154233
The model `l10n_pl_tax_office` has a group to be able to access it.
The Many2one that refers to it, `l10n_pl_reports_tax_office_id`,
does not.
Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust
Linked to runbot error 24602, 24721
closesodoo/odoo#154294
X-original-commit: dba837afe72c9e8b3e3f8e9615ddb923227d3af0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer.
In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation:
- Create a new transfer for each date_deadline
- Merge the move with distinct date_deadline
Usually, it makes sense to not merge moves with distinct date_deadline, but it also makes sense to not create a new resupply transfer every day.
So for now, we treat this situation as a limitation, but we still provide a workaround:
By adding a system parameter, we give the possibility to the user to ignore the date_deadline when merging moves.
## HOW TO REPRODUCE:
- Create new Warehouse 'Warehouse 2' WH2
- Create Custom Route to resupply 'WH/Stock' from 'Transit' From 'WH2/stock' (see screenshot)
- Create product P1 (storable, with custom route selected)
- Create reordering rule on default warehouse, with min=1, max=1, route=custom route
- Create Sale Order for 10 units of P1, confirm => New Receipt from 'Transit' -> 'WH/Stock' generated
- Wait 1 day (alternative is to increment the Lead Time on the Stock Rules).
- Create Sale Order for 10 units of P1, confirm => Same Receipt used, 2 lines are present.
OPW-3633551
closesodoo/odoo#154276
X-original-commit: 8bed8f89cf2faf635f3148a747429241cbdfe460
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Before this commit:
- When coupen code template is selected and we drag text block then
text will not be visible because of bg color as the background color
and text color are same.
After this commit:
- Now in coupen code we can see text in text block.
task-3514347
closesodoo/odoo#154137
X-original-commit: 6cf35c7e192eacdffcec08b176325504e51b2aa2
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Issue:
------
On the calendar application, it is not possible to create a 15-minute event
directly from a selection using the mouse.
An event with a default duration of one hour is created.
Cause:
------
The fullcalendar library detects two events:
- a date selection
- a click
The date selection is correct, but the size of the "rectange" is the same
(15 minutes is the smallest unit in terms of size).
As a result, a click using a default time is detected.
Solution:
---------
We can use `preventDefault` to block the second event (the click)
because the event is the same.
Note:
-----
This fix is safer than patching the `FullCalendar` library
(which may change in future versions).
opw-3743945
closesodoo/odoo#154135
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
dhrp-odoo