Create a new Journal Entry
Add a 100$ debit line 1
Add a 100$ debit line 2
Add a new line: system will suggest 200$ credit line 3
Save
Delete line 3
Change line 2 amount into 50
Create a new line
Issue: the system will compute a credit amount of 50$
This occurs because in the onchange we work with a new record
representing the set of changes
Commands sent by the orm are:
- DELETE of line 3
- UPDATE of line 2
So in the new record we don't have information on line 1.
A solution is to recover the data from the stored record
opw-3757415
closesodoo/odoo#156875
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
- Install planning app.
- Go to planning app, and convert the view to List.
- Group by Resource -for example-.
- Notice how the allocated time values are mis-aligned with the header label.
Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.
The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
- both firstAggregateIndex` = `lastAggregateIndex` = -1
- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1
- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.
opw-3764616
closesodoo/odoo#156647
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Get to a list view where there's a monetary field AND the related currency
field in the same list.
Then insert the list in a spreadsheet.
=> Either the currency format is not fetched or the currency name, depending
on the order in the list.
Bug introduced by 8777973e
opw-3770057
closesodoo/odoo#157623
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before.
There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days.
To fix, we remove the constraint _check_positive.
To reproduce the issue:
- Go to Accounting -> Configuration -> Payment Terms
- Edit/Create a Payment Term with a negative value in the 'After' column
- When saving, a Validation error appears
task-3751491
closesodoo/odoo#157600
X-original-commit: fe1399a1821a05638c638fc4f0437a7aed70e260
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In all cases, we will fetch the record since we display the name, so it
has no extra cost to slug the record instead of the id, and it will
prevent an extra redirect from /tag/1 to /tag/name-1 on click.
opw-3752989
closesodoo/odoo#157578
X-original-commit: c406220277a3005cde34a44ba733d470769c2dc4
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Steps
-----
1. Create a time off request, approve it and add a document.
Issue
-----
The details of the time off request are not visible when the attachment preview is displayed.
opw-3792894
closesodoo/odoo#157024
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Issue: When editing with the editor an event and removing the title
we get an issue since the url that we usually got is formatted like:
'/event/title-3/register' where title is our event title and 3 the id,
but when leaving the title blank the url will change to be like:
'/event/3/register' in this case the match will no longer find anything
since we no longer have a '-' on our url.
Steps to reproduce:
1. Install website_event and go to the website view of any event.
2. Edit the event, and leave the title blank.
3. Save, and try to edit again the same title.
Solution: We can directly get the id without the preciding '-', in this
case we will get the id in both cases without having mismatch error.
opw-3783998
closesodoo/odoo#157534
X-original-commit: ed236a2097f962dbb39f3cb0b8b9f099285fa0e3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The cost of sales accounts need to have the type expense_direct_cost for the Gross Profit calculation in the Profit and Loss report to be correct
closesodoo/odoo#155374
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In this pr I renamed account 220100 to KRA - VAT payable and created the new KRA - VAT receivable accounts. These accounts are now used as the Tax Payable and Tax Receivable accounts on all the tax groups
closesodoo/odoo#153646
Task: 3725559
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, it could happen that the More dropdown was
displayed, but it only contained a single stat button. This isn't
what we want, as that single button could simply be displayed
instead of the More dropdown toggler.
Task 3778382
closesodoo/odoo#156241
Related: odoo/enterprise#58565
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
- Create a shiping method based on rule
- Set margins and then swith back to fixed price
Bug:
since this PR https://github.com/odoo/odoo/pull/108794
margins aren't displayed on the form anymore for fixed price
but they are still set on the model if we edit the delivery type
opw-3759128
closesodoo/odoo#157452
X-original-commit: 79bc772c8d48f64e0bd41fa0f5a40b1cd853293f
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Emphasize the preview with colors and field borders to:
- visually outline the preview result
- clarify to the user that there are editable fields which customize the preview
closesodoo/odoo#155367
Task: 3751514
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, when an error occurred during the installation of a
data module, there was no displayed error nor a rollback to remove data
already installed from the module.
This commit makes sure that, if an error occurs, it is displayed through
a UserError that will do a rollback to remove every record from the
module.
closesodoo/odoo#148823
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
In the German localization, "Sales Order" MUST be translated as
"Auftragsbestätigung". In all other cases it can remain as
"Verkaufsauftrag".
Term was previously corrected but then overwritten by accident during
fw-port that used old translation.
closesodoo/odoo#157496
X-original-commit: b4cd19a456242dea6ad7bddc2efaf17382ffb453
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In rework of accruals plan, we removed the possibility to set a time off type on the accrual plan directly.
The field has been removed from the form view, but not from the list view.
closesodoo/odoo#157366
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit the Email Sent Count (located in the Communication
tab of the event view) wasn't including emails sent to the attendees who
weren't confirmed.
[This commit changes]
Event mail scheduler will include seats_uncofirmed into calculation of
the mail_count_done which is the count of emails sent. This is
reflecting the actual number of emails sent.
[Reproduce]
- Install event_mail,event_sms
- Create event E starting in time T (Events/Events)
- Add an "Unconfirmed" attendee (Modify state via database write)
- Add an E-Mail in the Communication tab of the event E
- Set Interval time > T,
- Template: "Email Reminder"
- Trigger "Before the event"
- Run scheduled Action sending email (Scheduled Actions / Event: Mail Scheduler)
- BUG: email sent, but not included in the sent count in the communication tab of the event E
opw-3693626
closesodoo/odoo#157229
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
A subcontracting BoM sometimes shows negative values in Overview, if
components are available in subcontractor's location.
closesodoo/odoo#144702
Task: 3607854
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The condition to decide which moves to consider to create new
orderpoints is incorrect. For example any move from a location that
is sublocation of the main warehouse location should be considered
as a out move. The inverse condition doesn't make much sense.
closesodoo/odoo#157459
X-original-commit: 7c123a5c1d8ed8bf856d4701a972f59737323646
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
Andrea Grazioso (agr-odoo)