Steps to reproduce:
- Install Sales, Accounting and Inventory apps.
- Go to Inventory > Configuration > Products > Product Categories.
- Open All / Saleable / Office Furniture and:
- Set the Inventory Valuation as Automated
- Set the Costing Method as First In First Out (FIFO)
- Go to Inventory > Reporting > Inventory Valuation
- Open the toggle header then Click on the plus button at the header.
- In the popup shown -Notice how the current value is 0-, set:
- Added Value to 1000
- Counterpart Account to 600000 Expenses
- Click on REVALUE, a new report appears.
- Open the newly created report > Other Info, open the Journal Entry
- In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`.
Investigation:
- the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34
- Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids`
- When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field
- That's why now `current_value_svl` is the new value and not the old one.
opw-3715522
closesodoo/odoo#157450
X-original-commit: 065b6632b133d780543c9f40beb536c2ff37ff52
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Issue -->
In `_onClickSaleOrder`, we load in the partner on the sale order using
`load_new_partners()`. However, the search on the `res.partner` model made in
this method has the potential to return every single `res.partner` record
because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785
After doing so, we check if the parter has been loaded and we grab the id using
`get_partner_by_id`. If the partner is not loaded, we use `_loadPartners` to
load them.
Since we are already checking and reloading the partner on the sale order
using `_loadPartners`, using `load_new_partners()` earlier is redundant.
Solution -->
Remove the try-catch block that loads multiple `res.partner` records during
the process of clicking a sale order via POS.
opw-3619941
closesodoo/odoo#157469
X-original-commit: b47e7bdd15e0738b479153fec495d009aeae9967
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Aditya Dasgupta (adda) <adda@odoo.com>
In one2many, for the view, the attribute to hide a field should
be column_invisible and not invisible
closesodoo/odoo#157356
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
To reproduce:
=============
- In the Settings: Product prices displayed on the website set as "Tax Included".
- Created a test product (for example price 100$ tax 15%).
- Created a price list with fixed price 15$ for all products
- Pricelist configured as "Selectable" and set to "Show public price & discount to the customer".
- on the product shop page, the price is 17.25$ instead of 115$ (which is the correct).
- add product to cart and check the cart price, it's 17.25$ instead of 100$.
Problem:
========
The undiscounted price displayed on the cart didn't consider the website
configuration (tax excluded/included).
Solution:
=========
Consider the website configuration to show the expected undiscounted
amount.
opw-3771242
closesodoo/odoo#157357
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Previous fix: odoo/odoo#139013 added in the ability to handle a use case
specific avoided due to its complexity and it being an edge case. I.e.
the ability to do a Put in Pack in a batch picking where there is a
shipping connector involved (i.e. when the `choose_delivery_package`
wizard is opened).
Because the ability to handle this situation is now added to stable, we
have to sort of support it now and handle it not breaking other flows.
Here are the flows that need to be handled (and were broken by the
previous PR): [In all cases, "Packages" setting needs to be activated
and each picking needs at least 1 move of a consumable/storable product]
Flow 1: batch picking + put in pack for single picking
- Create 2 pickings of any operation type
- Create a new batch picking with these 2 pickings
- Open 1 of those pickings directly (i.e. not in the batch)
- Click on "Put in Pack"
Expected result:
Only the move from the open picking is put into a package
Result before this commit:
Both pickings have their moves put into the same package
Additional notes: Because this is not an obvious bug, users may already
had this bug occur in their DBs without realizing it
===
Flow 2: batch picking (or multi-record calling of `action_put_in_pack`)
[different in v17 onwards due to removal of immediate_transfer boolean]
- Create 2 pickings (of different picking types)
- Select both pickings (through direct call in shell or rpc) and call
`action_put_in_pack`
Expected result:
Moves are blocked from being put into same package since this situation
doesn't make sense (i.e. the products are moved to different locations
but the package can only be in 1 location)
Result before this commit:
The moves will all be put into the same package
Additional notes:
In theory batch picking creation has checks to avoid batches where
there are pickings with more than 1 picking type or have different
`show_reserved` values, but because `_package_move_lines` is a method
that can be called in different use cases (including multi-record
pickings) via customizations/future code changes, we add in checks to
prevent put in pack from finishing in those cases to avoid unexpected
behavior/stack traces. I.e. remember to respect existing
`self.ensure_one` checks since they're probably there for a reason.
===
Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where
none = a different carrier than having 1)
- Create 2 delivery pickings with different `carrier_id` values (i.e.
different shipping methods assigned to them)
- Add both pickings to a batch
- Click "Put in Pack" in the batch picking
Expected result:
None, we should not handle this case because if the products are in the
same package then the same package info will be sent to both carriers
and the user will be double charged for every move (or
charged(/potentially create the wrong shipping documents) when it
shouldn't be in case of no carrier for one of the pickings)
Result before this commit:
All moves are put in the same package and the double
charging/potentially incorrect shipping documents will occur
Additional notes:
This is the use case that was intended to be avoided when flow was
originally decided to not be handled
closesodoo/odoo#157224
X-original-commit: b3498facab77e1eed8969c018e3f966a80e62654
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce the bug:
- Open the homepage and enter edit mode.
- Click on the "Theme" tab.
- Select the 4th color from the theme options and choose "black".
- Drag and drop a "Search" snippet onto the page.
- Save the page to exit edit mode.
- Enter text in the searchbar input.
- Bug: The text is not visible because its color is the same as the
background color of the input.
This bug appeared since this commit [1] where the "bg-light" class was
added to the searchbar input. This caused the text color of the input,
which by default is the same as the body color, to become invisible when
the background color of the body is dark.
To fix this, we now adjust the text color of the input based on the
background color of the input.
[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20
task-3751401
closesodoo/odoo#156042
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Steps to reproduce issue:
1. Have Sales installed
2. Enable Analytic Accounting and create two Projects
3. Go into both Project Settings and add distinct Analytic Accounts
4. Create a Vendor Bill
5. Add a Product Line and put both accounts in the Analytic Distribution
6. Add an account in another column to one of the existing Analytic Distribution Lines
7. Go to Projects and open the Project Updates of the Project whose account was alone in the Analytic Distribution Line
8. You get the error:
> invalid literal for int() with base 10: '[int],[int]'
Explanation:
With commit odoo@dc696c8ed4850a83b6af721002a90f2944891923, the way IDs are stored changed. They are now computed in a csv string.
A part of the Analytic Accounting pipeline didn't get updated after that change, making a lot of the features not working properly.
Suggested fix:
- We must take into account the multiple analytic plans in any order possible in the ID search.
- Because the amount of `account.move.line` can increase rapidly, the new ID search must be indexable.
- We reworked the counting query to avoid `account.move` being counted multiple times.
opw-3626619
closesodoo/odoo#147664
Related: odoo/enterprise#54311
Signed-off-by: William André (wan) <wan@odoo.com>
The goal of the `def new` override on `account.payment` is to have the
`journal_id` computed when creating a payment in the form view.
The problem is that it is also called by the onchange when a field is
modified.
This is causing a bug:
- Go the the cash journal and change the name of its payment methods (so
you can distinct them from the ones of the bank journal).
- create a payment (do not save)
- switch the journal to "Cash" then switch back to "Bank".
-> the "Payment Method" is still one from the "Cash" journal.
The fix here is a hacky way of checking this is the call on the
record creation.
closesodoo/odoo#157407
X-original-commit: 816a170a10969a7785fdcf2f9dffe461108ca16c
Signed-off-by: William André (wan) <wan@odoo.com>
When a live chat starts with a bot, the channel name is missing the
operator and the visitor name. This makes it challenging for live chat
managers to review the session history.
This PR resolves the issue by updating the channel name when an
operator is found.
closesodoo/odoo#157385
X-original-commit: 725316e22f52780c7c96aedebbd9f5c4700bb3b2
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Co-authored-by: Matthieu Stockbauer <48757558+tsm-odoo@users.noreply.github.com>
__Current behavior before commit:__
When the field `website_id` of a user is set, this user should only be
able to login via this website (cfr. [this method][1]). This means that
he can only login if [`get_current_website`][2] returns the same website
as `website_id`.
The issue is that when login with RPC, `dispatch_rpc` is making a
[`borrow_request`][3] which hides the `request` object from the RPC
layer. This has the consequence that `get_current_website` is not able
to retrieve the website based on the url of the request. Thus preventing
a user to login via RPC even if the domain used corresponds to the
website set in its `website_id` field.
__Description of the fix:__
Add the possibility to retrieve the current website via
`threading.current_thread().url` (which is set [here][4]). This way it
is possible to know the current website even if `borrow_request` has
been used.
__Steps tor reproduce:__
- Install `website`
- Go to Website > Configuration > Websites
- Set the domain of the first website (e.g. `http://localhost:8069/`)
- Go to Marc Demo" res.partner form view
- In Sales & Purchase tab set **Website** to "My Website"
Then run this script in another terminal:
```python
#!/usr/bin/env python3
import json
import urllib.request
url = "http://localhost:8069/jsonrpc"
dbname = "db-16.0"
def rpc_login_user_demo():
"""
Login with demo using JSON-RPC
:return: the user's id or False if login failed
"""
req = urllib.request.Request(url=url, data=json.dumps({
"params": {
"service": "common",
"method": "login",
"args": [dbname, 'demo', 'demo']
},
}).encode(), headers={"Content-Type": "application/json"})
response = json.loads(urllib.request.urlopen(req).read().decode('UTF-8'))
if response.get("error"):
raise Exception(response["error"])
return response['result']
uid = rpc_login_user_demo()
if uid:
print("Login success")
else:
print("Login failed")
```
The login will fail but it should succeed since we sent the request with
the same host than the website domain.
opw-3742591
[1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/res_users.py#L40
[2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944
[3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361
[4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037closesodoo/odoo#157372
X-original-commit: b8bc400909012dd04d383287a1850bfc96dd0c5c
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Steps to reproduce:
- Install Accounting
- Connect with a user without "Administration: Settings" rights (e.g. Marc Demo)
- Go to "Accounting / Accounting / Journals / Journal Items"
Issue:
An Access Error is raised when trying to access a "ir.ui.view" record
that is restricted to "Administration/Settings" group.
opw-3787114
closesodoo/odoo#157363
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the changed test sometimes failed because we
expected the image to be set, but it wasn't (yet). This commit
increases the delay.
Runbot error 56099
closesodoo/odoo#157347
X-original-commit: 289e2b20673ba44fb8ce7afe19bae3bfa94e5f8c
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
When we apply a text color and change its font size, the text color defaults to
black. This occurs because the default black color is applied to a span within
`o_basic_theme.o_layout`.
After this commit:
Now, when applying text color and adjusting its font size, the color of the text
remains unchanged.
task-3770351
closesodoo/odoo#156602
X-original-commit: 6c305ee13ad56ce99e3146a162d28094554b92d7
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- have two companies; Company A and Company B
- create a product Product A and set a different cost in each company
- create an invoice for Company A with Product A and post it
- Go in invocie analysis > pivot view and set the y-axis as 'move'
Issue:
The invoice will be taken twice
Issue:
for Product A, there are two ir_property lines (one per cost/company)
opw-3753395
closesodoo/odoo#157268
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce the issue
- order something from the website and pay
- create an invoice for the SO (invoice is paid) and confirm it
- add an extra item to initial SO
- create a second invoice
- check the invoice on the portal
==> second invoice is automatically marked as paid because of the
transactions on the SO
The transactions that were used on the SO are filled in on the new
invoice in the transaction_ids field. In the view in the portal the
method 'get_portal_last_transaction' is called which finds the
transaction for the older invoice and assumes its paid.
We will now rely on the payment status of the invoice instead of the
state of the last transaction.
opw-3594556
closesodoo/odoo#157267
X-original-commit: 2e7872e73a016cc82cd6fe0fbe84a06870972591
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Since [1], image options like "Filter" are kept when a user changes the
position of an image in an "Image Gallery" snippet. [1] also adapted the
`snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder`
from version 16) to test this behavior. To do so, the test adds a filter
on an image in an "Image Gallery" snippet, checks that the filter is
displayed on the editor panel, moves the image, clicks on it and finally
checks that the filter is still displayed on the editor panel. The
problem is that the steps that check if the filter is displayed on the
editor panel are the same before and after the move of the image which
means that the second check is true also before the move of the image.
This situation is a typical case where an undeterministic error could
happen. Indeed, we do not know if the second check tests an old value or
an updated one.
To solve the problem, the test has been adapted; after the move of the
image, the test clicks somewhere else (on the footer in this case), and
then back on the moved image to finally check that the filter is still
displayed on the editor panel. The goal of the click on the footer is to
be sure to have a loaded version of the editor panel. By doing so, we
remove the risk of an undeterministic error situation where a condition
is already true before an action is done.
Note: this problem has been discovered because the test
`snippet_image_gallery_reorder` succeeds on version 16.3 without the fix
of [1]. Now, the adapted test fails on version 16.3 without the fix of
[1].
[1]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3717041
closesodoo/odoo#157207
X-original-commit: e7a17fd27abed655258856a83668552c2930170c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
BaseModel's sorted() has two problems:
- It breaks the prefetch of self for no reason
- When it is called without an argument, it filters out new records
because the search() used in sorted() doesn't return new records.
Keep the same prefetch as self to fix the first problem.
We partially fix/support the second issue, we just avoid filtering out
new records (but we don't actually sort them)
closesodoo/odoo#157145
X-original-commit: 0551c3b7e8e1469dabdb19d6420c544a1654fec5
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce issue:
1. Download Accounting (or Sales or just Invoices)
2. Open Accounting
3. Create Company 2 and switch to it
4. Open Accounting again
5. Remove Company 2
6. Open Accounting
7. You receive an error:
> ValueError: Expected singleton: onboarding.progress(1, 2)
Explanation:
In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all.
https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69
This is due to the fact that some onboardings are not related to a company while others are.
After that, getting the `onboarding_state` will trigger an `ensure_one` check.
In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it.
Suggested fix:
`ondelete` decorator requires the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade.
opw-3762382
closesodoo/odoo#157142
X-original-commit: 8e3283aabfd93a78eb4d72c4fd97f6a20ad08ef4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
Switching to RTL mode would inadvertently revert the domain picker,
causing a disruption in the email format. The expected format is Alias@domain,
but it was displaying as domain@alias.
After this commit:
Now, the domain picker remains intact in RTL mode, ensuring that
the email format is correctly displayed as alias@domain.
Task-3624012
closesodoo/odoo#157091
X-original-commit: 26f67d4b4c5dbddd6d543949c4c6071e53c53515
Related: odoo/enterprise#58364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Create an accrual plan to give 1 day per month
- Create an allocation with this plan
- Update date_from and/or accrual_plan_id
- number_of_days is updated
- Set date_to in the past (1)
- Update date_from and/or accrual_plan_id (1)
- Set date_to in the future (1)
- Update date_from and/or accrual plan
- number_of_days is updated
Actual results:
- (1) number_of_days is not updated
Expected results:
- number_of_days updated on date_from/accrual_plan_id/date_to change
opw-3764865
closesodoo/odoo#157030
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
When an employee is created from a signed application, the phone number or the mobile number was not copied to the employee private information.
Now, the phone number is copied and if not present, the mobile number is copied.
closesodoo/odoo#157055
Task: 3659409
X-original-commit: cd1fc0bc7e3c8206e8e9e70f5f255f9c4f2b47eb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The way we cache the image is not right when that image is not on the
current record. For instance displaying a partner/user image. The unique
key used is not related to that record.
Introduced by https://github.com/odoo/odoo/pull/97544closesodoo/odoo#157199
X-original-commit: d127ec26d8e8d42c0e25668797cbd0f37203dc52
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: fja-odoo <fja@odoo.com>
Currently, when we color a list of links with more than three items in
the list, only the first and last links are colored.
Now when the li element is colored in a list, the font element is
created inside the link. We also make sure when the font size is defined
the font element is created inside so that the background color is
aligned with the font size
task-3677214
closesodoo/odoo#157280
X-original-commit: 4ffb15ab9d9bc7fe6d358264c1ee1ed4e48e5956
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
The goal of this commit is to only use one global `resizeObserver` to
adapt the text highlights on resize.
task-3285817
closesodoo/odoo#142968
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to improve the current text highlight code
by adding the following updates:
- The editor's code (`_handleTextOptions()`) will only set text
highlight classes and activate the snippet. Highlight DOM adaptations
(multi-line detection, setting SVGs...) are done by the public widget.
- The `o_text_highlight_item_dirty` class is no longer used to adapt
non-detected highlight items (the highlight mutation observer was
tweaked to detect and adapt the new highlight items added to the DOM
after editors commands. E.g. after the `oEnter()`).
task-3285817
Part-of: odoo/odoo#142968
A `z-index: -1` is used on highlight SVG to make sure they appear behind
the text they highlight. However, it should still appear above
the background of the column/snippet behind that text. To make sure of
that, a new stacking context was created, using `z-index: 1`. While this
works... it also changes the z-index value, making it possible for
highlighted text to appear above other elements for no apparent reason.
This is replaced by a more appropriate `isolation: isolate;`.
task-3285817
Part-of: odoo/odoo#142968
Co-authored-by: qsm-odoo <qsm@odoo.com>
The goal of this commit is to update the `selectStyle` options to handle
the default CSS `"currentColor"` value.
task-3285817
Part-of: odoo/odoo#142968
After introducing the text highlights feature in [1], the text overlay
opacity was reduced for more highlight visibility on small text, leading
to a visible text overlay even on scroll.
The goal of this commit is to fix this behaviour by forcing the opacity
to 0 when the overlay should be hidden.
[1]: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066
task-3285817
Part-of: odoo/odoo#142968
Before this commit, the free product reward feature in a Next Order
Coupon program was not functioning as expected. This commit fixes this
issue, ensuring that free product rewards are correctly applied in Next
Order Coupon programs.
opw-3703485
closesodoo/odoo#156008
X-original-commit: 8da5ea1a7cb26bffe7045b1dc325c24b6f9a2af7
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
**Current behavior:**
When enabling the option which specifies that products should
be displayed with their prices including tax, the dialog which
appears when a user is buying tickets for an event has a label
at the top of the window which lists the range of prices for
the available tickets. This price range does not include tax
irrespective of the status of the aforementioned option.
**Expected behavior:**
Displayed prices should adhere to the configuration which has
been selected in the db settings.
**Steps to reproduce:**
1. In the Settings app, give the `Display Product Prices`
configuration setting the `Tax Included` selection
2. In the Event app, select an event and give at least one
ticket type a nonzero cost
3. Go to the website, select the event which has the modified
ticket prices, and click the Register button
4. The label atop the dialog window displays pretax prices
**Cause of the issue:**
The database setting does not affect anything in the XML which
is responsible for displaying this price range label.
**Fix:**
Set the all_prices value to be calculated respective to the
website setting that indicates whether to include or exclude
taxes when displaying prices.
opw-3734299
closesodoo/odoo#157253
X-original-commit: 4e0afec6beed75462eb86f044b968b4a7af7f45a
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Steps to reproduce:
-------------------
- go to time-off analysis (by type);
- group by "Requet Type" and use list view;
- click on an allocation;
Issue:
------
We don't have the record for this allocation.
Cause:
------
Commit [^1] removes the `allocation_id` field, so it is no
longer possible to retrieve a record from the
`hr.leave.allocation` model.
Solution:
---------
Place the allocation id in the `leave_id` field and use the
`leave_type` field to determine the model
(`hr.leave` or `hr.leave.allocation`).
opw-3748884
[^1]: a1949ca541closesodoo/odoo#157204
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
*: account_edi, hr_work_entry_contract, l10n_ch, l10n_latam_check,
mail_bot_hr, sale, sms, survey, website_slides, pos_online_payment
This commit follows the margin variable introduced in the
`form_controller.scss` file. It removes the margin customizations
applied on the alerts which are rendered above a form sheet to let the
CSS rule handle the spacing.
task-3577058
closesodoo/odoo#156927
Related: odoo/enterprise#58282
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Since Milk redesign the margin bottom on the alerts displayed above the
sheet in a form view should be mb-2 (equivalent of the margin-bottom of
the statusbar). Some alerts across Odoo were still inconsistent.
This commit introduces a custom property `--alert-margin-bottom` which
allows the customization of the alert's margin bottom depending on its
context.
This ensure that an alert rendered in the form view above the form_sheet
will receive the appropriate margin as long as there is no utility class
or override on the alert with this property.
There the last alert gets a margin of mb-2 and if multiple alerts are
displayed the ones above the last one get a margin equivalent to mb-1.
task-3577058
Part-of: odoo/odoo#156927
In commit 355250d, the domain was adjusted to automatically select the
invoice document type for customers with a RUC and limit others to the
"boleta" document type. This generally holds true, except for export
invoices requiring the 01 document type. This commit addresses the
current restriction, allowing the selection of document type 01 other
than "credit note boleta."
closesodoo/odoo#154511
Related: odoo/enterprise#56465
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit addresses the erratic behavior of the mobile menu when
clicking on menu items linked to anchors instead of navigating to
different pages. The issue occurs in mobile view and can be reproduced
by following these steps:
1. Create a page longer than the height of the screen with 3 blocks.
2. Add 3 links to target different sections on the page.
3. Create 3 menu items linked to the newly created anchors (/#...).
4. Save to apply the modifications.
5. Switch to mobile view.
6. Open the hamburger menu.
7. Click on the first menu item, then the second, then the third,
and again on the first one.
Upon reproducing these steps, the scrolling event would pass through
all the anchors. This occurs since [1]. This commit introduces fixes to
ensure proper navigation when clicking on menu items in mobile view,
resolving the described issue.
[1]: https://github.com/odoo/odoo/commit/cb1ad42130b52334992aba2f10bb91798b23a7a6
opw-3652930
closesodoo/odoo#150810
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is possible for a cron to be executed twice at a same moment if the
cron is currently being executed by a cron worker and that a user click
on the "run manually" button from its form view.
closesodoo/odoo#157203
X-original-commit: a45f171eabdb571465d6245bf2a6bccecab53fa0
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The INFO "Starting job x" and "Job x done" logs are only logged for the
automatic executing of the cron by the cron worker. When running the
cron manually via its form view, no INFO was logged.
The technical support is reporting problems where a cron server action
is running twice at a same moment leading to problems such as
mass-mailing sending emails twice. There is a mutual exclusion mechanism
for cron workers but no exclusion mechanism seems in place for http
worker vs cron worker. Logging the "run manually" actions will help us
figuring out the problems.
X-original-commit: fcc2eabc671557e610688eac93bae333b0a2c119
Part-of: odoo/odoo#157203
In UBL 2.0, the Note node can contain the narration field of an invoice.
Its content can be some complex HTML.
Some localization (e.g. l10n_pe) doesn't support some special characters like
'\n' or '\u00A0'.
This fix allows the localization modules to format the value used by Note node.
opw-3744946
closesodoo/odoo#155081
Related: odoo/enterprise#57268
Signed-off-by: Laurent Smet (las) <las@odoo.com>
When there's a payment that involves public user, an error will occur when they've input the email
3789416
closesodoo/odoo#157195
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug:
- Go to an event "Introduction" page
- Enter edit mode
- Click on the pre-existing "Introduction" title (note that it cannot
be removed because of the way the page is built, we might want to
improve that in master)
- Save it as a new custom snippet
- Go to your homepage
- Drop that new custom snippet that was saved
=> It cannot be removed, the rest of the content is kinda broken as
wells, etc etc.
This is because the original branding was saved with the snippet.
Indeed the event pages are made in such a way those pre-defined titles
are snippets but which are "editable root elements", i.e. elements
whose ancestors cannot be edited since themselves or their neighbors
contain dynamic elements.
opw-3633326
closesodoo/odoo#157191
X-original-commit: 356b8ce1070243ce69b5ba75d4988fcee6bc6190
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
AH-Yussef