-Step to reproduce: create a custom module and try to extend method in
website_slides controller like this:
@http.route(sitemap=sitemap_slide_view)
def slide_view(self, slide, **kwargs):
return super(WebsiteSlidesSeo, self).slide_view(slide, **kwargs)
From there, 'rule.endpoint.original_routing' will take the value from
the extend method not the original one therefore user will one again go
to the the forbidden error page which is'n friendly. We shouldn't access
original_routing because that's the "function's specific @http.route"
closesodoo/odoo#160864
-solution: we only need rule.endpoint.routing because it is the one holding the "merged @http.route accross inherited controllers".
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported.
closesodoo/odoo#157811
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steuernummer was being validated at tax report xml generation. The check was moved to the company form view.
Moreover, the field was set visible in the company form view for multivat.
It should be a constraint raising when trying to set the steuernummer to the company; there is no point in only checking it at XML generation.
task-3809218
closesodoo/odoo#161423
X-original-commit: c8543f716164d9e1f7e5b39908ff9805c9cc53bd
Related: odoo/enterprise#60496
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Hesham Saleh (hsal) <hsal@odoo.com>
steps to reproduce:
- Go to Accounting > Accounting > Actions > Lock Dates
- Set a Tax Return Lock Date to a date of the previous month
- Create and confirm vendor Bill with a taxed line of positive price
- Go to Accounting > Reporting > Audit Reports > Journal Report
- Hover over the Vendor Bills and click on "journal items"
- Add the optional vehicle field to the recods
- Select your expense line and try to add a vehicle
> Invalid Operation "You cannot modify the taxes related to a posted
journal item..."
Cause of the issue:
Modifying the "vehicle_id" of the account move line will trigger a call
of the `_sync_dynamic_line` method in order to modify other account move
line linked to the same account move:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287
During the call of this write method, the account move line that we
did not directly modified will not be excluded:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571
as `..._field_will_change(line, vals,"vehicule_id")` will be `True`.
The error will therefore be raised two lines later because a 'tax_id' is
present in vals as a 'tax_id' was set on our related account move line.
Expected behaviour:
Since the 'tax_id' present in vals is the same as the one already set on
our account move line, we are not modifying the taxes related to a
posted journal item and we should not raise the error.
opw-3810718
closesodoo/odoo#161387
X-original-commit: 3cd87c61c852eef96195a39a4011a6baa39e3078
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Only delivery carriers that can communicate with the outside should be deactivated.
Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated.
Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases.
@moduon MT-5612
closesodoo/odoo#161182
X-original-commit: bdaeae0230fe0da7743f8cc4ed9dcb210b994540
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Issue:
- when creating an accrual plan based on attendance,
the duration is not computed accurately when allocating.
- the computation is not correct if you select a different
start date in the allocation without emptying the field "Allocation"
Steps To Reproduce:
- In the time-off app create an accrual plan: where employee
accrue 1h for every hour worked based on attendance.
- In the attendance app create a new attendance for 8 hours.
- add a new allocation to Mitchell Admin with the plan you created.
- Change the date on the validity period, new allocation is 8h.
- change the date again and notice the Allocation not computed correctly.
Solution:
- In `_onchange_date_from` when simulating how many days an
accrual plan would give from a certian `date_from` we don't reset
`number_of_days` to 0. reseting it to 0 fixes the issue.
opw-3793961
closesodoo/odoo#160696
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
We add the following demo data:
-Invoices, credit and debit notes, both from customer and supplier
-Examples of rates
-Data from Uruguayan partners
We also adjust demo data of the company.
closesodoo/odoo#145112
Ref: ADHOC 34810
Ref: LATAM 1132
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This commit fixes an issue about the search panel content being cut in
some accounting interfaces. This is due to the fact that the searchpanel
with a specific class would get an arbitrary width value in px.
To avoid this issue, we set a `w-auto` to the searchpanel, allowing it
to adapt its width to its content.
task-3560617
closesodoo/odoo#161382
X-original-commit: f90339c0c6fc27bab7e21d2e78bec043f6327146
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
The test test_tz_legacy will fail if the taget does not exist on the
operating system. This is breaking in some versions of the tz-data
package. Don't make this test fail if the target is missing.
closesodoo/odoo#161341
X-original-commit: 276eb0192fdddb736453857c18bf9f0cccecb4a3
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce issue:
1. In settings, activate Timesheets
2. Go to _Project > Tasks > All Tasks_
3. Create a new task
4. Give the task a title
5. Choose an Assignee
6. The title disappeared
Explanation:
The title field, `display_name`, is a computed field that gets its value from `name`. This compute has dependencies coming from other computed values. Those dependencies lead to other dependencies up to `project_id`. Because of it, changing `project_id` will trigger `_compute_display_name`.
Suggested fix:
Backporting odoo/odoo@8178ad79bb, the cause of the issue is the same.
opw-3823040
closesodoo/odoo#161276
X-original-commit: 89b1ff812ecd4186f2196341d72fe7e6380404dd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Before this commit, users could not disable the Terms and Conditions display on the product page from the Customize tab of the web editor. To remove it from the product page, the only workaround was to remove the text in that div.
Now, a button will be available in the Customize tab of the web editor to quickly show or hide the Terms and Conditions.
closesodoo/odoo#161354
Forward-port-of: odoo/odoo#161230
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
`_UNSAFE_ATTRIBUTES` was changed from a `list` to a `set` in odoo/odoo#151989.
odoo/odoo@cde2781591
Reset it to a `list` as before, by retro-compatibility concerns,
in case developers used features not working on `set`.
For instance:
- `_UNSAFE_ATTRIBUTES.append`
- `_UNSAFE_ATTRIBUTES.extend`
- `_UNSAFE_ATTRIBUTES + ['foo']`
The opportunity is taken to add `_co_code_adaptive`,
which is a new attribute added from Python 3.11,
hence available from Ubuntu Noble.
Firstly added as `_co_quickened` in
https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7b153de6cdd
Then renamed to `_co_code_adaptive` in
https://github.com/python/cpython/commit/2bde6827ea4f136297b2d882480b981ff26262b6
The opportunity is also taken to move `mro` out of the `Python 2 functions` section,
as `mro` is available in Python 3, hence making the comment confusing.
Part-of: odoo/odoo#151989
Before
======
In E-invoice Value is pass as other values
After
====
No RC value is pass to the E-invoice because not required to pass RC value.
closesodoo/odoo#161125
Signed-off-by: Josse Colpaert <jco@odoo.com>
Description:
Add indexes affecting queries related to `account.analytic.line`.
Based on heuristics like domains in `search`/`read_group` that are
not really selective, or being an inverse of One2many.
Some of these searches are on code-paths that are frequent, like
creation of an SO.
The goal is to reduce the number of Seq.Scan or non-selective Index
Scan.
Reference:
task-3724844
closesodoo/odoo#160472
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Have a form view that has twice the same x2many field, excpet the first one is invisible=1.
The second occurence has a context with the form_view_ref key.
The x2many should have at least one record.
```xml
<form>
<field name="x2m" invisible="1" />
<field name="x2m" context="{'form_view_ref': 'some_ref'}">
<tree>
<field name="display_name" />
</tree>
</field>
</form>
```
When opening a record, the context was not taken into account, yielding the wrong form view to open that record.
After this commit, the form_view_ref context key is taken into account, and the right form view opens.
opw-3845448
closesodoo/odoo#161253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current Behavior:
The description of the "Interviewer" access rights is the following:
"Interviewer right will give access to all job position/applications
where the employee is defined. It will allow to refuse, plan meetings.
**Chatter content will not be available.**"
However, the "interviewer" users have access to the chatter as no
sensible content can be accessed from it.
> The description therefore needs to be updated.
Note:
This access right did not exist before saas-16.4
opw-3783965
closesodoo/odoo#161197
X-original-commit: eb2facc88701ca7deaa02947ee9e6c30687c0588
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Configure an email alias for the journal 'Vendor Bills'
Send to the mail alias two pdf bills
Issue: Only 1 record is created with the 2 bills as attachment
The system should split the bills into separate records, but this does
not occur:
- after the first bill is processed the current move extract_state is
'waiting_extraction'
- when the system check whether to extract data from the second document the
result is negative as it check the state of the first document
opw-3822262
Co-authored-by Andrea Grazioso <agr@odoo.com>
closesodoo/odoo#160983
Related: odoo/enterprise#60168
Signed-off-by: William André (wan) <wan@odoo.com>
Since commit [1], we can now drag and drop an image column by dragging
it directly, and not only by the move handle. Commit [2] allowed the
image to be dragged from anywhere and not only from the top middle.
However, since commit [2], it is really difficult to drag a column
downwards in a grid, if the drag started from the bottom move handle or
near the bottom of the column if it contains an image, because we easily
get out of the dropzone.
Indeed, since the positioning of the column now takes into account the
mouse position on the column where the drag started, the mouse cursor is
therefore located under the column (or almost under in the second case).
This is why it gets out of the dropzone before a new row could be added.
For the second case, new rows can be added, but only if the drag is slow
enough, which is not convenient.
This commit bounds the vertical position of the mouse when dragging, in
order for it to always be considered inside the column, so it cannot
escape the dropzone anymore. A safety margin of one grid row is
considered, to not escape when dragging rapidly.
Steps to reproduce:
- Drop enough snippets to have a scrollbar or select the "Sidebar"
header template.
- Drop a "Text-Image" snippet
- at the top of the page if the header was changed at the previous
step, or
- at a place where the top of the snippet can be hidden with a scroll.
- Toggle it to grid mode.
- Start dragging any column with the bottom move handle or drag the
image column by clicking near the bottom of the column.
- Go over the grid dropzone if the move handle is used.
- Drag towards the bottom of the grid.
=> The mouse easily gets out of the dropzone, making it impossible to
add new rows and drag further down the grid.
[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9
task-3601336
closesodoo/odoo#144427
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Since commit [1], we can now drag and drop an image column by dragging
it directly, and not only by the move handle. Commit [2] allowed the
image to be dragged from anywhere and not only from the top middle.
In grid mode, in order for the column to stay well inside the grid when
dragging, its computed position was originally bound horizontally, to
the left and the right of the row. With commit [2], it is now also bound
vertically, to the top and the bottom of the row.
While it makes sense for the top, because we need to take into account
from where we dragged the image, it should not have been the case for
the bottom, as we need to overflow in order to add new rows. This
resulted in the drag towards the bottom becoming jumpy, because it locks
on the bottom of the grid until a new row is added, when the mouse
pointer is down enough.
This commit removes this bottom bound, in order for the drag towards the
bottom to be smooth again.
Steps to reproduce:
- Drop the "Text-Image" snippet and toggle the grid mode.
- Drag a column towards the bottom in order to add new rows.
=> It is not smooth: it locks on the bottom of the grid.
[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9
task-3601336
Part-of: odoo/odoo#144427
Before this PR, the chatbot script would hang when redirected to a
page where the chatbot is not enabled.
When such a scenario occurs, we should restore the chatbot's state to
where it stopped, and the script should continue.
This PR fixes this issue.
task-3625853
closesodoo/odoo#161121
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Prior to this commit, the tour service would fail to observe changes
in the tour's shadow DOM after the tour was resumed.
A mutation observer waits for the shadow host to appear in the DOM,
then registers it with the macro engine observer in order for the
macro engine to take shadow DOM modifications into account.
This commit ensures that the same logic is applied when resuming a
tour.
Part-of: odoo/odoo#161121
Steps to reproduce the bug:
- Install e-commerce.
- Open a product page in edit mode.
- Click on the "product.description_ecommerce" field.
- Bug: an infinite loop starts. The "selectionchange" event is triggered
in an endless loop, causing various issues such as the page freezing
after a while.
This issue was introduced by this commit [1].
Since this other commit [2], when a selection itself is the main
container of the editable area, we replace this selection to only
include the content of it. With commit [1], this has been modified to
take into account "oe_structure" and "[contenteditable]" elements. As
these elements can be empty, clicking on them would reselect them,
creating an endless loop since we'd never leave the condition that
replaces the selection.
[1]: https://github.com/odoo/odoo/commit/e93fa23c29421ffe8917d9650330585d6dad210f
[2]: https://github.com/odoo/odoo/commit/10c5a16cd44b8d8e54082df90166f2309dfa788d
task-3830033
closesodoo/odoo#160535
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add support for the Malaysian Peppol PINT specialization,
allowing to generate the related XML file.
This also adds a few additional features that are in the
specifications:
- SST registration number, needed in the xml and on the
invoice.
- TTx registration number, needed on the invoice.
Both numbers are optional, but if the business is registered
in any of them they are required to display these on the
invoices and they are required to enforce some rules. (cannot
send taxes that are not 0% "Out of scope" if not registered with
SST, ..)
Task id # 3647922
closesodoo/odoo#159407
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
The logger show "Job done" before the flush. But if during the flush an
error appear (sql constraint, validation error during computed field,
...), the log contain "Job done", but is not True.
The time to compute the cron is not good because it doesn't contain the
flush time.
closesodoo/odoo#161204
X-original-commit: 0cde9c7238ece225ebd50c50f4a78d16ac6b5226
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit the time to unlink an account.move can take lot of time (60s on large database).
closesodoo/odoo#161172
X-original-commit: 73c1fdd192577bba56dcad213d8a22de8b5de06f
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Outlook and similar Windows based systems use windows-874 for encoding
Thai characters which is not natively known by Python.
Simply aliasing the Windows encoding as cp874 adds support for this
encoding.
opw-3684161
closesodoo/odoo#161117
X-original-commit: 65d4c2507e762dc273a02a2e2215c49a5976568d
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Add missing indexes on stock.move and mrp.workorder
to speed up search_read on mrp.production. That's mostly
useful at the opening of the Shop Floor app.
closesodoo/odoo#160349
Related: odoo/enterprise#59998
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
due to the absence of IR model data entries for certain
account taxes, but with identical tax names, tax types,
and scopes, attempts to create standard taxes with the
same names alongside IR model data result in a constraint
violation, specifically, "tax name must be unique." To address
this constraint, we append "old" to the tax name for existing
taxes lacking IR model data entries.
see:
https://github.com/odoo/odoo/blob/740fb9ac8c8e121820feeac0e1f25a304e47da9d/addons/account/models/account_tax.py#L202
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4864, in _create
records._validate_fields(name for data in data_list for name in data['stored'])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1456, in _validate_fields
check(self)
File "/home/odoo/src/odoo/17.0/addons/account/models/account_tax.py", line 201, in _constrains_name
raise ValidationError(
odoo.exceptions.ValidationError: Tax names must be unique!
```
closesodoo/odoo#161146
X-original-commit: 87e13a0f29ace57f1fd591d7180a64bb085a3bca
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Add the same tag to 13 different blog posts.
- On the "Blog" page, click on this tag to filter the blogs.
-> Problem: the result displays "12 Articles" but they are actually 13.
In this case, the result displays "12 Articles" as they are 12 articles
on the current page. When going on the second page of the results,
"1 Article" is displayed. This problem is solved by displaying the total
number of articles found after the filtering operation rather than the
number of articles on the page.
opw-3802729
closesodoo/odoo#161137
X-original-commit: 4e90dc9096cbcf9f2fe7f251b247c8d62bc0bc5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Before this commit, when the user created a new quotation from
Contact->Opportunity-> ("New Quotation" or "Quotations/orders widget
button", archived records could be added to the quotation
(e.g. ,product, taxes...) because the context was set to
active_test = false. After this commit, the context is configured back
to active_test = true when creating a quotation from opportunity.
opw-3802796
closesodoo/odoo#161087
X-original-commit: 3085c3b24bef719c3cf63ec9d3b5a7d7b2a34037
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When user tries to empty start date or end date in website using editor,
a traceback will appear.
Steps to reproduce the error:
- Install "website_event"
- Go to Website > Events > Open any Event > Register > Edit
- Now try to empty start date or end date > Save
Error: A traceback appears:
"TypeError:'<' not supported between instances of 'bool' and
'datetime.datetime'"
https://github.com/odoo/odoo/blob/4759c6d1ee09c32381dc56c59c95949fd0e2807c/addons/event/models/event_event.py#L507
Here, When user tries to empty start date or end date,
start date or end date will become "False",
So it will lead to the above traceback.
solution:
A try-catch is used to catch typeerror at write of qweb fields.
sentry-5038057541
closesodoo/odoo#161083
X-original-commit: c893ff16e277b46796a943c5532e01e8edf8958f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Currently, there is an access right problem concerning timesheet. The
module mrp gives write access to portal user on analytic line, but it is not
something we want for the project app.
step to reproduce:
- install hr_timesheet on a saas-16.3 db
- go to project app, open office design
- select any task, and add a subtask to it
- go the the view form of the subtask
- create a new timesheet for this subtask
- go back to the view form of the parent task
a button 'subtask timesheet' is now visible
- share the project in edit mode with a portal user
- connect with that portal user
- open the office design project
- go to the view form of the parent task and click on the button
- the user is redirected to a view tree with the timesheet of the
subtask
this view tree is editable
Source of the problem:
in the mrp module, the access rights of the analytic line is overwritten
to give write access to it to portal user.
Soluce:
We have to make the view in readonly mode for timesheet when the
connected user is a portal one. Unfortunately, it is not 100% possible
because setting the field to readonly still gives the user the
opportunity to click on those fields (which triggers access errors). So
we have to create new views and specifically open those views when the
user is a portal one.
affected version: saas-16.3 - master
task - 3751315
closesodoo/odoo#160959
X-original-commit: 7b733f118f60ff98d9f82c69453187d70e6bece0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The sale_stock module patches the ProductCatalogKanbanRecord updateQuantity method
to prevent the quantity to go under the delivered quantity of the product
The issue is that we are also using the ProductCatalogKanbanRecord in the industry_fsm_stock module
in which the services product added to the sale order are considered by default but we would like to be
able to dimish their quantity in the catalog (in case of a missclick for exemple)
Since the service product can't be considered delivered in sale modules, the condition in updateQuantity
shouldn't change anything
Task-3689939
closesodoo/odoo#155157
Related: odoo/enterprise#55455
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
Install web_studio
Change language to French
Open any form view and enable Studio
Add a datetime field and click on it
In french we have the following message:
"Première date acceptée": Date formatée ISO ou "aujourd'hui" He says that we can use the string "aujourd'hui"
when we only expect "today" in English.
This commit changes the help text to display "today" in every language
opw-3829954
closes odoo/odoo#160904
Forward-port-of: #160144
Forward-port-of: #159654
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Steps:
- Install sales app.
- Go to settings of sales.
- See header field there is no download button.
Issue:
- Binary field should have download button and
user should be able to download file with out
issue.
Cause:
- Since Settings is abstact model so it does not
contains id field in it and download button visibility
depends on id field.
Fix:
- Extend binary field for setting view to get proper
file from related field where actual file is stored.
task-3620555
closesodoo/odoo#160070
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This module was introduced in saas-16.4. In that version the sale
order report and portal template displayed both price_subtotal and
price_total for each sale order
line. 655d375af8 removed price_total.
Because this module removes price_subtotal we end up with no line
total at all on the default Brazilian quotation PDF and portal
view (just 3 columns: description, quantity and unit price).
Loosely inspired by l10n_cl [1], this commit changes our approach to
turn the two places where we use price_subtotal into price_total. The
aforementioned commit also changed the heading of this column from
"Subtotal" to a more generic "Amount", so there's no inconsistency
there. Although this is a bit of a mess, I can't think of a better
solution.
[1] https://github.com/odoo/odoo/blob/655d375af83dd49bbbd5f5818e319c3b0e9778c1/addons/l10n_cl/views/report_invoice.xml#L173-L175closesodoo/odoo#159794
Related: odoo/enterprise#59703
Signed-off-by: Josse Colpaert <jco@odoo.com>
Fix various "Using variable xxx before assignment". It was not detected
by pylint <= 2.5.0 which was the version enforced on runbot.
closesodoo/odoo#160886closesodoo/odoo#161166
X-original-commit: 328a0ce2fa619376672c591d8b4f8892aaa2da1a
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fixes the 'og:site_name' metadata, which previously
defaulted to the company name (see [1]), causing issues for multi-site
setups. Now, the metadata actually uses the site name.
Steps to reproduce:
- Navigate to any page
- Right-click and select "View Page Source"
- In the <head> section, observe the meta property "og:site_name" set to
"MyCompany".
[1]: https://github.com/odoo/odoo/commit/156955de6b4e6288ac606d29b843081842154eff
opw-3791082
closesodoo/odoo#161123
X-original-commit: 24ea3ca4b12f8dd4103a650436a144e776b81d83
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce the issue:
-Drag and drop the rating snippet.
-Change the score from options.
-Notice that spaces between icons disappear.
In the release notes[1] of jQuery 3.5.0, it's stated that security
fixes related to the HTML parser were implemented. Consequently,
self-closing e.g. `<i/>` tags inside function arguments were replaced
with e.g. `<i></i>`. As a result, trailing spaces lost significance,
causing icons to stick together.
Before the commit:
Prior to Odoo 16.2, jQuery 3.3.1 was utilized, which allowed the use
of self-closing tags in the append function. This behavior was as
expected.However, starting from Odoo 16.2, jQuery version 3.6.3 was
adopted.
After the commit:
Instead of using self-closing `<i/>` tags, `<i></i> ` with a trailing
space was used. This trailing space gained significance due to the
prefilter no longer ignoring it. Consequently, icons no longer stick
together after changing the score.
task-3576760
[1] https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/closesodoo/odoo#161076
X-original-commit: b897e836697a288bbd58a8efc340d9f7b2e76e30
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This ensures that the user will not click on the confirm button before the record is saved which will prevent unnecessary UserError if the Timeof type requires no validation
closesodoo/odoo#160839
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When writing in a discuss channel, the updated value sent to the client
should be read from the database, not directly from the values passed to
the write method.
Partially backport of https://github.com/odoo/odoo/pull/139563closesodoo/odoo#158860
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When the user adds a valid Mauritius phone number, it is not correctly parsed by
the phonenumbers library, resulting in a user error while sending a WhatsApp
message to that number.
Steps to produce:
- Create a new contact with the Mauritius country selected.
- Add a phone number (e.g., '+23057654321').
- Try to send WhatsApp messages using this phone number.
- This will throw an Invalid number error.
Problem:
`phonenumbers==8.12.1` python library is used in odoo for parsing phone numbers.
The `8.12.1` version is too old and cannot parse Mauritius phone numbers
correctly.
Solution:
The `8.12.13` version accurately parses Mauritius phone numbers. Currently, The
latest version of the phonenumbers library is `8.13.31`. Hence, the latest code
from the latest version of the phonenumbers library is monkey-patched into the
system.
Task - 3799632
closesodoo/odoo#161039
X-original-commit: c3743b5fcfb5d67c442e5eee9f084b684e4baac3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date.
Now journal entries will match the date of the expense when it is an expense paid by company.
closesodoo/odoo#160990
X-original-commit: 77d53dd3d62016f97c19645b42c772204babdd45
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Logan Staelens (lost) <lost@odoo.com>
When creating a product document, it was still possible to save
something that wasn't a pdf. The check only happened when modifying it.
opw-3802795
closesodoo/odoo#160879
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce:
-------------------
- create a time off accrual plan with:
- cap accrued time equals to `True`
- maximum leave equals to `0 days`
- create an allocation with this accrual plan
- run the scheduled action "Accrual Time Off: Updates the number of time off"
(make sure you have the right "lastcall" and "nextcall")
Issue:
------
The number of days of the allocation is set to zero.
This scenario makes no sense from a business point of view.
In effect, we are blocking the accumulation of allocations at zero.
The result is that there will never be any days allocated to these allocations.
Solution:
---------
Add a constraint to force a maximum leave number
when cap accrued time is set.
opw-3847408
closesodoo/odoo#160626
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
When a register payment is made with a writeoff in foreign currency
and when the user set manually an exchange difference account,
don't create a write-off. Instead, 2 cases to consider:
- When the payment is expressed in a foreign currency different than
the invoice's one, play with the rate between amount_currency and
balance and let odoo making an exchange difference accordingly.
That way, the payment has no write-off and the invoice is fully paid.
- When the payment is expressed in company currency but the invoice
has a foreign currency, force the exchange difference to use a rate
that will fully paid the invoice without creating any write-off line
on the payment.
task_id: 3717436
closesodoo/odoo#157398
Related: odoo/enterprise#58511
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Nguyễn Đại Dương