**Issue Description**:
Users encounter a misleading confirmation page when a payment is canceled or fails in version 17.0 and higher of our website. Specifically, upon a payment error, users are directed to /payment/status with an error message. However, selecting the "Skip" button redirects them to a confirmation page titled "Thank you for your order", suggesting successful payment. This misleading information can lead to confusion, especially since it results in the card being cleared for public users despite non-receipt of payment.
**Steps to Reproduce**:
1. Navigate to the 'Shop' section of the website, add a product to the cart, and proceed to checkout.
2. Click the "Pay with demo".
3. Select "Canceled" as the Payment Status and then "Pay".
3. Click the "Skip" button during the payment process.
4. Observe redirection to a confirmation page with the title "Thank you for your order", implying successful transaction.
**Proposed Solution**:
This issue, present in versions 17.0 and later, is due to a modification in the <template id="confirmation">, where the "Thank you for your order" title is now displayed regardless of the payment state. To resolve this, we propose introducing a conditional check to display this title when the payment state is "pending" or "done", ensuring accurate representation of the transaction status.
opw-3688785
closesodoo/odoo#151304
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
On a big database, the search for journal entries is basically not
usable.
This is because there is a missing index on the reference, as well as a
complex OR generated by the clause `('move_id.partner_id', 'ilike', self)`.
This commit will of course add the index, but will also remove the
clause because it is almost always possible to find the journal entry
via the partner by using the right filter instead, and since it is not
really an easy to discover "feature" it is most likely not even used.
On the test database, queries went from over 2 minutes to less than 1
second.
closesodoo/odoo#151222
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit, users were unable to successfully revert the 'done' status
of slides.
Technical Reason:
In this commit https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b, the transition from qweb.render to the
Owl render engine (renderToElement) was done. This caused a problem when trying
to undo the 'done' status of slides. The issue was that using 'true' as a
boolean in Owl turned it into an empty string. This fix solves the problem by
making sure we use '0' or '1' as boolean values in Owl.
After this commit, user can revert slides 'done' status.
Task-3667904
closesodoo/odoo#151006
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Since #135113, calls to /im_livechat/get_session can become very
expensive on large databases with a long history of livechat sessions.
Operators who have thousands of past livechat sessions (channels) can
cause the SQL query in get_operator() to take multiple seconds.
When the livechat is set to auto-popup and there are lots of visitors,
this can become very significant.
This patch changes two aspects:
- introduce a CTE for the RTC session part, in order to avoid a
JOIN cardinality between livechat channels and channel_members - we
only care about channel membership for a RTC session
- restrict the selection of livechat channels created within the last 24h,
considering that we only care about messages sent in the last 30
minutes anyway
The second part may change the result ordering in the present of old
channels (>24h) with recent messages - but that is rather unlikely, and
an operator will be selected anyway.
This change makes a huge difference on a database with 300k livechat
channels and 1 million `discuss_channel_member` records, from several
seconds to >50ms. The results are identical or extremely similar in most
cases, and the database only needs to look at a few hundred records
instead of millions.
closesodoo/odoo#150968
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Steps to reproduce the bug:
- Enter edit mode.
- Click on the "Theme" tab in the options panel.
- Click on "Add a Google Font" in the "Font Family" select.
- Paste the address of a font page in the input.
- Disable the "Serve font from Google servers" toggle.
- Save the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Click on the "Remove" button for the recently added font.
- Confirm your choice to close the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Bug: the font has not been removed.
This bug appeared with commit [1]. With the transition to the Owl
render engine, the 'true' value passed as a parameter in the
'delete_google_font_btn' template, defining whether a font is local,
wasn't being set as the attribute value in the template.
In this Owl context, 'true' indicates the attribute's presence, not its
value. To address this, we replaced the boolean 'true' with the string
'"true"' to ensure the parameter value is correctly passed to the
template.
[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b
task-3714768
closesodoo/odoo#152715
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Create a storable product X1:
- Route: MTO + buy
- Vendor: Azure Interior
- BoM:
- Type: subcontractor
- Subcontractor: Azure interior
- Component: any component
- Create a MO:
- product: P1
- Component: X1, qty: 3
- Confirm the MO
- Go to the created PO
- Confirm the PO
- Go to the picking
- receive 2 units of P1 and validate it
- create a backorder
- Cancel the backorder
- Try to update the purchased qty in the PO line to 2
Problem:
A traceback is triggered:
File "/home/odoo/src/odoo/addons/purchase_stock/models/purchase.py", line 542, in _prepare_stock_move_vals
'picking_id': picking.id,
AttributeError: 'bool' object has no attribute 'id'
Solution:
When updating the quantity in the purchase order, if no picking requires
an update, it is better to avoid creating a new picking and new moves.
opw-3681064
closesodoo/odoo#152577
X-original-commit: 0da5d6cc0c94320ad39fe9b930dde4b0ef6feff5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
- Create a new user with no affiliated sales team
- Activate custom mail server with an alias domain
- Login with new user
- Check pipeline in CRM
- The empty pipeline message will show the wrong alias
Issues:
The alias displayed is not for the team of the user.
opw-3608263
closesodoo/odoo#152563
X-original-commit: f862673885aa8fad9b8b225d020cd2757d7be013
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Since commit [1], which removed jQueryUI for the drag and drop, the
history when editing breaks easily.
Steps to reproduce:
- Drag and drop "Text-Image", save and go back to edit mode.
- Click on a column, move it to the right using the arrow and then to
the left, still with the arrow.
- Undo: no issue, the column went to the right.
- Undo: nothing changed => the column should have gone to the left.
- Undo: the column goes to the left => there should not be a third undo
since we only did two changes.
- Redo: no issue, the column goes to right.
- Redo: nothing changed => the column should have gone to the left.
- Nothing to redo anymore => the column never goes to the left again.
This happens because with the new drag and drop, an `o_draggable` class
is added on the elements when their editor are started, which adds
mutations in the history. Even though it does not explicitely add a
step, these mutations are well reverted when undoing/redoing (e.g. this
is what happens when nothing changes in the steps to reproduce).
This commit fixes this history issue by ignoring the mutations linked to
the `o_draggable` class.
Note that commit [2] already fixed other `o_draggable` class issues.
This commit therefore fixes them in a more general way.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
[2]: https://github.com/odoo/odoo/commit/32a6729dd094d53eb4a653ebb9d69d2b8cbe2390
task-3698536
closesodoo/odoo#150687
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce the bug:
- Add a delay (for example 5 seconds) at the beginning of the
`/sale/get_combination_info_website` route.
- Add a delay (for example 10 seconds) in a `willStart` method in the
`Wysiwyg`.
- Go on a product page and enter edit mode.
- Click on the the product image.
-> The "Replace" button does not appear.
In this situation, the added delays represent slow rpc answers. Let's
analyse the flow of instructions in order to better understand the
problem:
- When you go on a product page, the `WebsiteSale` public widget is
started. `_getCombinationInfo` of `VariantMixin` is then called through
the `start()` of the public widget. As the rpc is taking time to answer,
`_onChangeCombination()` is not directly called.
- When entering edit mode, the `WebsiteSale` public widget is destroyed.
Due to the edit mode, the `o_editable` class has been added on editable
elements.
- After the first added delay and thanks to the rpc answer,
`_updateProductImage()` is called through `_onChangeCombination()`.
Because the `editor_enable` class has not been added to the document
body yet (due to the second added rpc), the `_updateProductImage()`
method replaces some elements of the DOM and by doing so, removes the
`o_editable` class of some elements. Consequently, the snippet option
linked to the image is not displayed.
The problem here is that the `_updateProductImage` method is called even
if its associated public widget has been destroyed. To solve the
problem, we first check that the associated widget is alive before
handling the result of the rpc answer in the `VariantMixin` mixin.
Note that the first idea was to use `this._rpc()` instead of
`ajax.jsonRpc()` in the mixin. Indeed, the advantage of using
`this._rpc()` is that it already ensures that the associated widget is
alive before handling the result of the rpc answer. The problem is that
some widgets that use the `VariantMixin` are created in such a way that
`this._rpc()` can not be used on them (for example
`OptionalProductsModal`).
Related to runbot-28700
closesodoo/odoo#149145
X-original-commit: 599e112ba7580617c61226b73355035c89af3395
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit solves an issue where sample data would be erased when the
user switches from a view with no sample data to another that should
contain them. This commit also removes unnecessary usage of nextTick in
assets loading.
Steps to reproduce:
- go to project and open one
- enter a no match filter and save it as favorite
- reload
- switch from kanban to calendar view and switch back to kanban
- after the fix, sample data should no longer be erased from kanban
task-3701143
closesodoo/odoo#152666
X-original-commit: a8ff1465c6c31240d06c98fa5d61e146b3908cf0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Ever since 14.0, from PR #45414, there has been a _compute_state
function for recalculating the state on holiday_status_id change
The reverted commit becomes unnecessary and causes incorrect action
buttons to be shown before creation
Note:
Reverts commit 015f8ecfa863ae2fcca983b6bb21e38577b220e7 from #82552closesodoo/odoo#152513
X-original-commit: 0c4a174d6a3c2615f4851cf3f39ca5159c40acfb
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Deleting an account or a plan shouldn't raise errors or provoke errors
elsewhere.
Since the `analytic_distribution` doesn't have a proper foreign key, an
account might be deleted while still being referenced. Because of this
the code needs to be defensive everywhere: we can't trust the content of
the JSON field.
Also, add tests to ensure that we can't delete a plan while the field is
still referenced in views.
closesodoo/odoo#152494
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Add an "Images Wall" snippet on the website.
- Add a link on the first image.
- Add a new image on the wall.
-> Problem: the first image does not have a link anymore.
When adding an image or reordering the images on a wall, the system
re-renders the snippet (see `nomode()`, `masonry()`, `grid()`) by adding
each images on the wall structure. The problem is that the system only
takes the images into account and not a possible image wrapped into an
anchor. This is now fixed as the system renders the images or the
wrapped anchored images returned by `_getImgHolderEls`.
The process is a bit different when adding an image or reordering the
images of an "Image Gallery" snippet. In this case, the system
re-renders the `website.gallery.slideshow` template. The problem here is
double: First, the template does not take a possible wrapped anchored
image into account. Second, there are only few image attributes that are
rendered by the template.
This leads to a new problem:
- Add an "Image Gallery" snippet on the website.
- Add a "Blur" filter on the first image.
- Click on "move to next" to move the first image at the second
position.
-> Problem: the image option does not show the filter and it is now
impossible to change some image options such as "Filter", "Shape" and
"Quality".
To solve those two problems**, the images rendered by the
`website.gallery.slideshow` template are replaced by the images (or the
wrapped anchored images) returned by `_getImgHolderEls`. By doing so,
the rendered images have the correct attributes (so the options can be
correctly displayed and modified) and they are still correctly anchored.
This commit also adapts the `snippet_images_wall` test. An extra trigger
had to be added on the `Select footer` step to ensure that the last
image of the wall has been inserted before clicking on the footer.
Without it, the tour fails as, if the moved image is in the first
position, the tour only waits for this image to be inserted in the wall
and then clicks on the footer. When the wall is completely built, the
focus is automatically done on the moved image and the step
`selectSignImageStep` fails to execute as its `extra_trigger` condition
(`.o_we_customize_panel:not(:has(.snippet-option-gallery_img))`) is not
met.
**: In this 16.4 forward-port, the second problem is not entirely fixed.
The task-3717041 will handle it.
opw-3535829
opw-3573135
closesodoo/odoo#152365
X-original-commit: e73a1a96dcf8786c01205ae0a97b10e38ab9afeb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The border color of 'color' filter attribute on /shop page corresponds
to the color od the body which makes it difficult for users to see the
color they selected.
task-3584558
closesodoo/odoo#141461
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This change hides the price range by default. It can be activated via the website editor if needed.
task-3235068
closesodoo/odoo#140277
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Resolves the conflict where two shortcuts (alt-c for 'new' and
'create invoice') existed, but only 'new' could be triggered.
Updates the shortcut for 'create invoice' to alt-i, ensuring
both shortcuts are functional and accessible.
task-3628572
closesodoo/odoo#146307
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Addresses the pixelation of tag images by adjusting their size
in the backend to 200x200. This change resolves the issue of
images being resized from 50x50 to 60x20 in the frontend, which
caused pixelation, ensuring improved image quality.
task-3607604
closesodoo/odoo#144724
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
Select a document in activity view to get its preview
Click the archive button => traceback
Before this commit:
The 'load' method of Activity Model led to the traceback while attempting
to set the domain of params, when none were received.
(bug introduced by : 7682286)
After this commit:
This issue is resolved by tweaking the code of 'load' method. In case of
default params, it now directly sets a domain, instead of trying to add a
domain to the one obtained in params.
Task ID : 3704340
closesodoo/odoo#152335
X-original-commit: 725ebab1f0c7ffc996414c85fbbd162afc4ecaf5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.com>
The patch method is not thread safe, which is very annoying for SH users
for instance.
One obvious issue is that during one thread patching the method, other
threads will also be impacted and have 100 decimal places for the
discount.
But it is even worse:
* thread A start: original = real_original; new = patchedA
* thread B start: original = patchedA; new = patchedB
* thread A end: reset original to real_original
* thread B end: reset original to patchedA
Now at the end of the transaction, the original method simply doesn't
exist anymore, and we only have one of the patches, which forces a
restart of the server to fix it.
opw-3552839
closesodoo/odoo#152168
X-original-commit: 9239ee3a95b474ce2eea92747b64f17f58c5c4cc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the issue:
1. Open Menu Items
2. Open the form to a menu
3. Select an action type (e.g. ir.actions.report)
4. Select another action type (e.g. ir.actions.act_url)
5. Click on the field next to it
6. Click on "View all"
7. The results displayed match the first action type selected (report), not the second (act_url)
Explanation:
`res_model` is initiated in two functions: `useOpenMany2XRecord()` and `useSelectCreate()` in the `setup()` of the `Many2XAutocomplete` class. The value is never updated for as long as this instance of the field exists.
Suggested fix:
Everytime the key changes, a new instance of the field will replace the current one, calling its own `setup()` with the updated values.
opw-3628017
closesodoo/odoo#151495
X-original-commit: d4078d783717986189f9fbc1b6dd6b264e41e49e
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Before this commit, we tried to access in javascript the cssRules
property of some stylesheets, to parse and display to the user
potential css errors, to help him to detect and fix them. [1]
Since a recent change [2], people get tracebacks on website pages
in odoo.com (without being logged in).
The issue comes from the fact that when assets are served via a
CDN (which is the case in odoo.com for not logged users), reading
the cssRules throws a CORS error. This error is logged in the
browser console.
We only spotted the issue since [2], because it delays the moment
we access the cssRules property (we wait for translations). Thanks
to that, the error service is ready and able to handle errors, and
it does display the error in a dialog, which allowed us to detect
the issue.
To fix the issue, we filter out stylesheets with a different
origin.
[1] 5e920db3ee
[2] 332268c724closesodoo/odoo#152696
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit:
While applying font color, when multiple picture snippet is selected the
color was not properly applied to the selection. It was observed that the
font was unintentionally applied around the figure which was preventing the
proper application of selected color.
After this commit:
It has been made sure that whenever the figure element is enountered it
should not be appended inside font tag.
task-3640901
closesodoo/odoo#152660
X-original-commit: 09a9dede95fbcc230a468913d188988cb9ad01e2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Emoji picker opened at an incorrect position.
After this commit:
- The Emoji picker now opens precisely at the cursor location
task-3569967
closesodoo/odoo#152645
X-original-commit: 7fd291355d555af229a33665f472db0811876299
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before, the tax tag invert is computed based on the entry type if the entry
type is different from "entry" or based on the tax set and the balance of aml
for entries with type "entry".
This is fine in most cases but we can reach a wrong tag invert if we use cash
basis and down-payment.
Here are the steps to reproduce:
- Create a company with cash basis tax (ex: "TVA 20% (Services)" for l10n_fr)
- Make sure no "base tax received account" is set in the cash basis settings
- Create a product with a cash basis default tax and an income account which is
not the default one
- Create an sale order with this product for 100€ + 20% tax
- Create a down payment for 30€ + 20% tax (add the tax to downpayment)
- Create the final invoice with deduction of down payment
- Register a payment on both to create the caba entries
=> Tax report will show 160€ of base instead of 100€
To have the issue, it's important that the income account of the product line
differs from the account used on the down payment line in the final invoice
because the issue involved having a negative base line in the resulting caba
move. If the same account is used for invoice down/product line the caba base
lines will be grouped in one non negative line. For the same reason, the
"base tax received account" must remain empty.
The deduction aml on the cash basis entry of final invoice have an tag invert
at False instead of True. So it's computed as -30€ instead of +30€.
If we reproduce the case with a non cash basis tax, it will work because the
move type will be different from "entry" and tag invert will be computed only
based on the type.
To solve this issue, we now compute the tag invert based on caba origin move
if any to improve the tag invert computation for cash basis entries.
opw-3597141
closesodoo/odoo#152575
X-original-commit: d780a2fc73259244411329027349fad1cb353f34
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Thomas Beckers (tbs) <tbs@odoo.com>
Steps to reproduce
==================
1. Go to the slides website.
2. Open any course.
3. Click on 'add a review' or 'edit review'.
4. Attach any files.
-> Files appear misaligned.
After this commit
=================
They will be perfectly aligned.
Task-3624281
closesodoo/odoo#152443
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Add support for `HALF-EVEN` and `HALF-DOWN` as value
for `rounding_method` argument of `float_round()`.
closesodoo/odoo#152227
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit will change the label to avoid the clash with account audit trail
module.
Also updating the pot of the localisation.
closesodoo/odoo#145149
Task: 3627720
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In the context of the bookkeeping act in denmark, we need to record all the
modification and delete of all the input, so we should by default install the
audit_trail module.
Since they need this in 17.0 we will make a bridge module.
Task: 3627720
Part-of: odoo/odoo#145149
Since 857c485175, rates are
not truncated anymore.
The stored rate value on SO, between SO currency and company currency
was not adapted and was still truncated, leading to invalid values
after rates conversion.
See also 5a621cea4c5a16998a3b83890144f81a3880244b where the same solution
was appied to pos orders.
opw-3638199
closesodoo/odoo#152592
X-original-commit: 6291424bd49a55f446f87c09af71fd13a1c13851
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps:
- Go to website and edit
- Add an event block
- Change the template of the block from picture to card layout.
- Replace the image of one card by a 4k image.
Issue:
The custom cover is blurry.
Reason:
By default the custom cover is resized to 256x256 (but not the default one because
it uses a static image path).
opw-3390459
closesodoo/odoo#152278
X-original-commit: d6d24ceb2a5b6e735ffb2fe1d5cea1f8f945f288
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Issue:
Possible to reproduce in 17.0: when adding a new field to the website
form of the "Extra Info" page in the eCommerce, a traceback is raised
(`OwlError: Missing template: "website.form_field_json"`) when the user
selects "Delivery Point Address" (`sale.order.access_point_address`).
Explanation:
JSON fields (which exist since [1]) are not supported as selectable
types in website forms, and they should not be because customers would
not be able to properly fill them out.
Fix:
Filter out all JSON fields from the list of authorized fields in website
forms; they will not appear in the list of selectable types anymore.
[1]: https://github.com/odoo/odoo/commit/7eeba9d205d2dace571b5d0895ddba6290a512db
opw-3596713
closesodoo/odoo#152545
X-original-commit: 28c3eb5878ad6f3d40a096803f3ba4aef5ef7937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug:
- In Website edit mode.
- Drag and drop a "Cover" snippet into an empty page.
- Sets the "Height" option of this snippet to "100%".
- Drag and drop a "Media List" snippet into the page.
- Drag and drop a "Popup" snippet into the page.
- Save the page.
- Scroll quickly the page to the bottom before the popup appears.
- When the popup is open, resize the window to trigger a "resize" event.
- Close the popup.
- Scroll the page to the top.
- Bug: the height of the "Cover" snippet is a way too high.
This bug occurred because the height of the snippet with the "Height:
100%" option enabled is calculated based on the scrollable element it is
in (since this commit [1]). However, when a popup is opened, the
detected scrollable element was incorrect due to the "overflow: hidden"
rule added to "#wrapwrap" by the "modal-open" class on the <body>.
[1]: https://github.com/odoo/odoo/commit/b371cb42cb67115692464c102813b7ebd54785d9
opw-3643498
closesodoo/odoo#152402
X-original-commit: 35b3f676820f7a19e842b3403a5ebcf956714a70
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
we execute a subprocess without checking if an error occurs
so we place the subprocess.call() in a try except
closesodoo/odoo#152331
X-original-commit: 4adda36260f3ba0fdf75688b419593006b80adb7
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Prevent an infinite loop when the cycle in the parents does not contain
the starting id: `3->2->1->2->1...`
Example:
```
>>> m=self.env['ir.module.category']
>>> c1,c2,c3 = map(m.browse,[1,2,3])
>>> c2.parent_id = False
>>> c3.parent_id = False
>>> c1.parent_id = c2
>>> (c3|c2).parent_id = c1 # this never ends
```
With current patch the call to `_check_recursion` successfully detects
the new cycle.
closesodoo/odoo#152080
X-original-commit: e7c6445dd1896bb182b44af768814f297027d3a4
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Before this commit:
- When a banner was inserted at the first line and Ctrl+A and backspace
is performed, nothing happens.
After this commit:
- Now, all the content except banner will be selected and removed.
task-3432167
closesodoo/odoo#151735
X-original-commit: 530f102720458e5e1c224bf38073cd763309bf0a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Performing ctrl+a and backspace inside a banner would unintentionally remove
its first element, which could be a block tag
After this commit:
- Now performing ctrl+a and backspace inside the banner will no longer remove its
first element if it's a block tag.
task-3432167
X-original-commit: ddc8587f8a712fdddaa714bee2931cb149c03a38
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner did not set focus inside the banner; instead, focus
was placed after the banner.
After this commit:
- Now, upon creating a banner, focus is now correctly set inside the
banner.
task-3432167
X-original-commit: 7327d20626ec9164f47e00f7094a36b8794db5de
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner after already existing content it's impossible to
go to the next line of the banner.
After this commit:
- It's now possible to navigate to the next line of the banner.
task-3432167
X-original-commit: 05a879f81ac59d47b718abbb5966fd4f8214e1de
Part-of: odoo/odoo#151735
Steps to reproduce
==================
- Use a laptop with touch or apply the following patch
```diff
diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js
index 21c6294b1b0e..64c4bc9b899c 100644
--- a/addons/web/static/src/core/browser/feature_detection.js
+++ b/addons/web/static/src/core/browser/feature_detection.js
@@ -62,6 +62,7 @@ export function isDisplayStandalone() {
}
export function hasTouch() {
+ return true;
return browser.ontouchstart !== undefined || browser.matchMedia("(pointer:coarse)").matches;
}
```
- Enable debug mode
- Go to contacts
- Hover the mouse over a question mark next to a field
=> Nothing happens
Cause of the issue
==================
The function `shouldCleanup` returns true when the device has touch and
the popover has been triggerd with the mouse
opw-3694156
closesodoo/odoo#152629
X-original-commit: 27242a0f1070b6b16c16e479e22dc0ccad0d9659
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The root of the issue:
The external identifiers are not guaranteed to be unique on their `name`
alone, the unique constraint is on the `name` and on the `module` fields.
Before this commit:
If a user or third party app were for example to create an external identifier
"project.autovacuum_job" and point it to an `ir.cron` record,
then that `ir.cron` would also be kept activated, which could cause
major issue if it makes calls to external systems, sends mail, etc...
After this commit:
All the crons are deactivated by the neutralisation, except for
the autovacuum
closesodoo/odoo#152535
X-original-commit: 0cc89a026d05b37714864e7ebb695e77ef2d1e7d
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Signed-off-by: Alexandre Moens (mao) <mao@odoo.com>
Some of the translation needed to be done or updated,
especially the ones about the warnings.
closesodoo/odoo#142596
Signed-off-by: Josse Colpaert <jco@odoo.com>
All the pre-sending checks that were done on the invoices before sending are now split by model, so that there's more separation.
ActionableErrors is used to show all the errors and give the user a quick action to fix the problems.
"These partners have an incomplete address, please verify xyz"
-> View partners ----> <partners view>
- Tooltip for IT XML export when readonly
We relied on the Italian xml export field's help tooltip before.
Now like other export options we have a dedicated <i> tag only shown when the field is readonly.
- Cannot change to test/official if you don't register
If you have Demo edi_mode, and you change to Test/Prod but don't register,
the EDI proxy user won't be deleted, and the edi_mode won't be saved.
So you think you changed to Test, but you haven't.
For compatibility in 17.0
- `l10n_it_edi_warning_message` must be maintained for the old view to work and make sense.
- Modified `l10n_it_edi_warning_message` becomes then `l10n_it_edi_actionable_errors`
Part-of: odoo/odoo#142596
`Model_get_actions_record(**kwargs)` helps building `ir.actions.act_window`
actions based on a certain model on very simple cases.
It opens a form if there's just one record, a list,form if there's more than one.
Given keyword arguments will overwrite those in the action.
This change serves as a base for the `actionable_errors` widget,
where it's used extensively to remove boilerplate code.
Part-of: odoo/odoo#142596
The new widget is meant to be a warnings header for wizards and forms,
where flows like EDI can list a series of errors and actions for
the users to fix the roadblocks.
The HTML result is an `<ul>` list with a point for each warning
and a link to a given action. Clicking the link will fire the execution
of a Python method on the backend, also passing back to it a series of
parameters the component has stored on setup time.
During setup, ActionableErrors accepts this structure as incoming data:
{
'error_key' : {
'message': _("Description of the warning"),
'action_text': _("Text of the link"),
'action_model': 'model.on.which.the.method.is.called',
'action_name': 'action_python_method_name',
'action_params': [...],'
},
...
}
A map is used instead of an array, so that the Owl framework
could be more precise in rendering changes in future development.
(i.e. remove a warning after clicking the action link
without re-rendering the whole widget)
This Widget will be used both for `l10n_it_edi` and `account_intrastat`
and can be embedded in many other occasions.
Part-of: odoo/odoo#142596
Before: When a user receive a mass_mailing and click on the
unsubscribe button, he arrives on the unsubscribe webpage where
the first sentence stay in english whatever the website language
Step to reproduce:
- Create a db with the email marketing and web module
- Create a mailing list with at least one recipient
- Send the mailing (catch the email with an email catcher, ex: mailhog)
- Click on the unsubscribe button
Now: The first sentence is in the website (or portal) language
opw-3538873
closesodoo/odoo#152579
X-original-commit: 6ba3dc277b9bf6b093eeefe889f20734ae4d135b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Slot params are dynamic content, similar to props, and are not
translated.
There is no point in adding untranslated content to the .pot files; so
this commit prevents the content of slot params from being exported for
translation.
Task-3718993.
closesodoo/odoo#152606
X-original-commit: b839faf09be259ffdccf9d872e646e4ebe4a8bcb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
ilru-odoo