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>
Steps to reproduce:
- Calendar > create an all_day meeting with an additional attendee
- Save > Edit > change starting date to a later day > traceback
Cause of the issue:
The write call of the method _onchange_date is applied to a pseudo record.
However, the write method expects a record with an integer id to
correctly _send_mail_to_attendees down the line.
Fix:
Since we don't want to send_mail_to_attendees anyway, we skip this part
of the write method using the already existing contextual escape
'is_calendar_event_new'.
opw-3733753
closesodoo/odoo#154091
X-original-commit: f206781b3f4cababa4e69c8c9586f0f5406acc83
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Before this commit, `.bg-view` was set to `.o_notification`. This was
creating an issue in the front-end where `.bg-view` doesn't exist,
making the background of the notification transparent and ultimately
causing readability issues. Issue introduced in [1].
This commit changes the way we apply the background from a utility
class approach to a SCSS approach. That way, we can easily override
in `website.scss` with the `$body-color` of the website.
task-3716367
[1] 4e1f0b8ea522accae4860937c2fb3815281e8483
closesodoo/odoo#154081
X-original-commit: f8f8d2905db633cfaaa93b6cd163f4ab55dc4c8f
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
-------------------
1. Install sale_project with demo data
2. Create a user with no access rights other than Project/User
3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update
4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More'
This will give an access rights error.
The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leading to an access right error.
This commit adds two sudos to avoid that error.
closesodoo/odoo#154271
X-original-commit: 8750b94c53c6ab58567873b0745fa6d9a18c97d0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit
=============================================
Before if all the lines were of service the error was displayed in a banner
after error in response was received, but now before sending request the lines
are checked if at least one line is of product and error is raised.
Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2closesodoo/odoo#154290
X-original-commit: 831d318a2993e8c4ac92739bf3604ad04dec924f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Pedram (pebr)