In the wowl codebase, we use luxon instead of moment to manipulate
dates. Moment was able to parse dates with short notations (e.g.
08/15/22 for the format MM/DD/YYYY). Luxon is more strict and does
not support those cases (the format must be perfectly respected).
As a consequence, moving from moment to luxon would introduce a
regression in our date and datetime fields. This commit implements
the same kind of logic as what is done in moment, in our date
parsers, such that those cases are handled.
Part-of: odoo/odoo#92475
This commit ensures that keys in the hash or querystring in the url
is URI encoded. Moreover, it properly handles the case where a
value in the hash is falsy. Before this commit, if a value, say "x",
was falsy, it resulted in the url in "x", which produces a crash
when decoding. With this commit, it generates "x=" in that case.
Part-of: odoo/odoo#92475
Steps to reproduce:
- Create an accural plan with two levels, the first should have
its action_with_unused_accruals set as lost. The second should
start one year after the first level.
- Use this plan on a employee and make it start the first day of
the previous year.
Current behavior:
The number of allocated day is wrong and can even be negative
Expected behavior:
The days of the first level are lost and there is the right amount
of allocated days,
Eplanation:
The _end_of_the_year function was first designed to be only called
on the first day of the year but the it changed since then without
updating it's content and it can calle any day of the year now. In
this case the use of today() does not make sense and it should be
replaced by the first day of the current year.
opw-2868297
closesodoo/odoo#94897
X-original-commit: 476818972e93b32df6f25cf299f631a8f7eb3af4
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
It could happen that there are other objects than stock.move linked to
the manufacture order. This is currently creating an error when
concatenating the objects. As we are only keeping stock.move objects to
log the exception on those, we should filter them before the concatenate
operation to avoid the error.
closesodoo/odoo#94893
X-original-commit: 1cdb682163e24fc01677cdcd0e1b83592443fffc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
Co-authored-by: vancleeff <mvw@odoo.com>
PR #75535 introduced trusted devices, but only made them visible in the
main user form (for admins) and in the portal.
It's quite useful for users to be able to view and manage their trusted
devices in their own user preferences as well.
This commit add them in the "Account Security" of the user profile.
In addition:
- improve the layout of the trusted devices by wrapping them in a
<group> to have them stand out from the surrounding prefs
- move the "Account is protected" label about the trusted devices, and
under main the 2FA toggle button, where it's supposed to be.
- removed the custom form view for trusted devices inside the one2many.
The point was to hide the extra `scope` field, but it's not worth it,
and the Cancel button wasn't even working, the default form view is
better.
- improve the confirmation message of the "Revoke All" button when it's
located on the user management form (for admins) to clarify that it's
not the admin's devices that will be revoked.
- change the 2FA label from "Your Account is protected" to "This account is
protected" when located on the user management form for admins.
Note: this is a manual partial fwd-port of #94111, as this part was
mistakenly dropped in the fwd-port chain at #94193closesodoo/odoo#94869
X-original-commit: d3a7910788ceff856fc6a843876579d379ce9caf
Signed-off-by: Olivier Dony <odo@odoo.com>
*: sms, snailmail.
The createThreadViewComponent helper was used during tests to mount
a thread view component and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient so that the thread view
component can be mounted in its real environment.
task-2871066
closesodoo/odoo#94691
Related: odoo/enterprise#28954
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
When the user hit ctrl+k on a mass mailing, no command palette nor link
dialog was opening.
This was due to the fact that the hotkey service would not react
to hotkeys being pressed from inside of an iframe element.
After this commit
One can now register an iframe to the hotkey service to let it react
to hotkeys being pressed from within the registered iframes.
task-2738457
closes odoo/odoo#91102
Forward-port-of: #89940
Forward-port-of: #82994
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Whenever the user hit ctrl+k when being on an html field, both the
link dialog and the command palette opened.
In order to resolve the conflict, now ctrl+k open the command palette
with the first entry being the command to open the linktool and
a subsequent hit to ctrl+k when the command palette is open to open
the link dialog.
Task-2738457
Forward-port-of: #89940
Forward-port-of: #82994
Part-of: odoo/odoo#91102
Before this change we would have to use other ways to add filtering forms in e-commerce. For example, using the context of the request in 'product.template' to catch what we need in the _search_get_detail method.
After these changes, we will not need to pass the context of the request outside the controller because it will be the _search_with_fuzzy options that will give us the information we need for inheritance.
closesodoo/odoo#94858
X-original-commit: d29f2f3ac5f8c3e8109287e0933609bdbe0cadb1
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit does a couple of small related improvements:
- adds new delivery options: "Local Delivery".
We replace the existing "Normal Delivery Charges" with the new "Local
Delivery" since it is now redundant.
- Originally a "Local Pickup" demo option was going to be added, but
this appeared redundant with the "[On Site Pick]" added in
odoo/odoo#87636 . Regardless, an additional `carrier_description`
field has been added so users can include extra instructions (e.g.
address to pick up from, when pickup can occur, etc) to sales orders/
confirmation emails (emails only via ecommerce sales).
- adds option to filter based on zip prefix rather than the previous zip
"range" option, which was too restrictive in some cases (e.g. in the
UK where zips can have letters in them). Note that users can view/edit
zip prefixes in menu under settings when debug mode is active. Note:
- prefixes are ordered by name so its easier to read large numbers
prefixes
- prefixes are always capitalized to avoid duplicate prefixes that
differ by case + avoid capitalizing all prefixes every time the
`_match_address` logic is called
Task: 2706451
Upgrade PR: odoo/upgrade#3384closesodoo/odoo#84620
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Description of the issue:
=========================
Suppose we have 3 articles with the following structure:
root
L child
L grand child
When granting the "write" permission to a user in "root", this user
will inherit this permission in "child" and in "grand child".
When we then restrict this user with the "no access" permission in
child, this permission is inherited by grand-child (correct).
Then, when a member is invited in the root article, the right is not
herited by "child" nor "grand child" (correct). However, this
permission is shown as being inherited from "root" in the permission
panel in "grand child" (incorrect: "grand child" does not have this
permission, and is in fact inherited from "child" as expected).
Solution:
=========
Add the boolean "article_is_desynchronized" check in the inner
join condition of the recursive SQL request used to fetch the
permissions of an article and its parents.
This boolean check allows to prune the recursion when an article
is desynchronized, so that the permissions of the parents of this
desynchronized article are not fetched, since they are not
inherited in the desynchronized articles nor in its children.
Some tests have been added to ensure the correct behaviour of the
share panel. Especially, the scenario described in the description of
the issue is tested.
Task-2866950
closesodoo/odoo#94834
X-original-commit: 252fce15f20a13ab3e71f7aafc247b5ac88a354a
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Description of the issue:
=========================
Suppose we have 3 articles with the following structure:
root
L child
L grand child
When restricting the internal permission in 'child', the inherited
permission parent id and the inherited permission of 'grand child'
are not updated, and the share panel shows that the internal
permission of grand child is based on 'root'.
The 2 fields of grand child (and of any other child of 'child' at any
depth) should be recomputed, and the share panel should show that
the internal permission of these children is based on 'child'.
Solution:
=========
Add 'parent_id.inherited_permission_parent_id' as field on which
'_compute_inherited_permission' depends on, so that 'inherited
permission' and 'inherited permission parent id' of the children of
an article are recomputed when the internal permission of this
article changes.
The scenario described in the issue description has been added to the
tests. One now ensures that if an article gets its internal
permission downgraded (either to 'read' or 'none'), the child and the
grand-child of this article have their inherited permission parent id
equal to the article and their inherited permission equal to the
internal permission of the article.
Task-2866950
X-original-commit: ea2d1b64c5f30c6d0e6a704b4f09c43084371b62
Part-of: odoo/odoo#94834
The vertical spacing between images of an images wall was lost when a
link was added to an image.
This commit applies the bottom margin to images even if they are
within a link.
Steps to reproduce:
- Drop an "Images Wall" block.
- Add 4 images to the wall.
- Add a link to the first image.
=> The gap between the two images of the first column disappeared.
task-2818919
closesodoo/odoo#94822
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Create an internal transfer and post it
The system will automatically create the paired payment
Now duplicate the transfer and post it
No paired payment will be created
This occurs because the field paired_internal_transfer_payment_id is
copied to the new record, linking the new intenal transfer to the old
paired payment, so the system will not create a new one
opw-2870995
closesodoo/odoo#94796
X-original-commit: 86a95de1aad3e27dabaf19d5deb4c14bdd87fa1f
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit, if one of the used payment methods was archived,
it would raise an error when loading the paid orders.
The solution is to load archived payment methods.
opw-2892321
closesodoo/odoo#94687
X-original-commit: 5c7b6bee2bdcaba0a2cde3d22d472e30640d9f09
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, when the admin had set his unsplash credentials in
the media dialog, he could search for unsplash images in the backend
(website builder, optimize SEO, html fields), but not on the frontend
(from the website_forum reply section for example). This was caused by a
wrong assets management for the media dialog views.
This commit reworks the assets_media_dialog introduced in [1], that were
not correctly defined. Until now, a web_editor.assets_media_dialog
bundle including js, scss and xml files was included in both the
web.assets_frontend and web.assets_backend bundles. It was built that
way, because the frontend only takes the views defined in the
web.assets_frontend bundle.
Two mistakes were made with that approach:
- The views defined in web.assets_backend are not added to the
webclient's templates list. Only the ones defined in web.assets_qweb
are. It was only working because web.assets_qweb was globally taking
every component view, defined as /component/*/*.xml.
- The qweb extensions templates for web_unsplash were defined in
web.assets_qweb (therefore, not included in web.assets_frontend and not
added to the frontend's template list).
To change that and include the web_editor and web_unsplash media dialog
views both for the frontend and the backend, a
web_editor.assets_media_dialog_templates is added, with the xml files
from the web_editor.assets_media_dialog bundle. But this time, this new
views-only bundle is included in web.assets_frontend and
web.assets_qweb.
When the public root's assets management is reworked and when it fetches
the templates from assets_common, these bundles should move to
assets_common, as discussed in [2].
Also, the extension template that adds the unsplash records is reworked:
the t-if is separated from the t-foreach, and set using an id instead of
the qweb instruction that it was using before, as it is more robust.
Finally, the isFetching getter was not set on the unsplash ImageSelector
patch, leading to a visual glitch ("No images found" was displayed while
querying unsplash). It is added in this commit.
task-2687506
[1]: https://github.com/odoo/odoo/pull/89223/commits/a154ee7ad6fd3ebdd38943e1439badae11c3151d
[2]: https://github.com/odoo/odoo/pull/89223#discussion_r895627061closesodoo/odoo#94572
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In expense flow the taxes are calculated as included in price.
Prior, to guarantee it, we had domain - ('price_include', '=', True) on taxes.
That could be inconvenient from user's point of view, as they first needed to
define taxes with price_include = True. That led to users duplicating taxes
between included/excluded just so that they could use taxes in expense.
Now we force taxes to act like price_include = True. This way, user does not
need to define taxes just for expense's purposes and still taxes will be calculated
as it supposed to be - included in price.
task - 2850882
closesodoo/odoo#94392
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When generating an alternative request for quotation from a dropship
purchase, the delivery address is not copied
Steps to reproduce:
1. Install Sales and stock_dropshipping module
2. Go to Settings > General Settings > Users > Manage Users, open user
Mitchell Admin and in the Access Rights tab enable 'Manage Multiple
Stock Locations'
3. Go to Settings > Sales > Quotations & Orders and enable Customer
Addresses
4. Go to Settings > Purchase > Orders and enable Purchase Agreements
5. Go to Sales > Products > Products and edit a product (e.g. 'Acoustic
Bloc Screens')
- In the Inventory tab enable routes 'Buy' and 'Dropship'
6. Create a Sale Order for this product with a different Delivery
Address then the Customer and confirm it
7. Go to the purchase order
8. In the Alternatives tab create an alternative
9. The Dropship Address is not repercuted on the new RFQ
Solution:
Add a method `_get_alternative_values` which sets the dest_address_id
and is extended in `purchase_requisition_stock` to add the
picking_type_id
opw-2880042
closesodoo/odoo#94109
X-original-commit: a7ef5d93650c262497d3a02b934284829cfc5021
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
15.3 introduced a new setting in the website to force users to sign
in/up whenever they try to buy something from the store.
This commit adds the mechanism to redirect the "process checkout" page
to the login page whenever the option is enabled and the user is not
logged in.
TaskId-2844980
closesodoo/odoo#90901
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*:
hr_contract
hr_work_entry
hr_work_entry_contract
This commit changes several views and methods to improve general usability of the payroll application
TaskID #2783013closesodoo/odoo#89311
Related: odoo/enterprise#26466
Related: odoo/upgrade#3534
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Create a sale order
- Set a very long message in the chatter
- Clink on the customer preview
Current behavior:
There is a empty space in the top right corner
Expected behavior:
The preview is a usual
Explanation:
The very long word in the chatter created at the
bottom of the page a very long message that increased
the page width, modifying the usual view. To fix that
we allow long words to broken to keep the same width.
opw-2880050
closesodoo/odoo#94802
X-original-commit: 775290e186f5dfdaae8a5b28e9ed20c6b307429e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Order discount do not take into account the discount on order lines so
the discount amount will be wrong
Steps to reproduce:
1. Install Point of Sale
2. Go to Settings > Point of Sale > Pricing and enable Coupons &
Promotions
3. Go to Point of Sale > Products > Promotion Programs and edit program
'Code for 10% on orders'
4. Change the Promo Code Usage to 'Automatically Applied'
5. Open a new session in Point of Sale 'Shop'
6. Add a product (e.g. Acoustic Bloc Screens, the discount is applied
with value 29.50$)
7. Apply a discount of 20% on the product, the discount value doesn't
change (it should be 23.60$)
Solution:
When computing the amount to discount, take into consideration the
discount already applied on the order line
opw-2883724
closesodoo/odoo#94791
X-original-commit: afb3e5516e43e831bec1fd6b6bc3aaa18fe3fde2
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Slightly improve `_compute_website_order_line` by reducing the
complexity when `website_sale_delivery` or `website_sale_loyalty` is
installed.
TaskId-2786691
closesodoo/odoo#90025
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Current behavior:
When returning a delivery that had a quanity lower than 1
the inventory valuation showed a value of 0 for the return
Steps to reproduce:
- Create a product that use "m" (meters) as UoM
- Change the configuration of the product Category
and set Costing method to FIFO and Inventory valuation to Automated
- Create a SO for this product with a quantity of 0.15
- Validate the order and validate the delivery with full quantity
- Now click on return and make a return for the delivery
- Validate the return and go in the inventory valuation
- Show the inventory valuation for the created product
- The return has a value of 0 when it should have the same value
as the delivery
opw-2880153
closesodoo/odoo#94827
X-original-commit: 9bc3d5ebef234aa1d77f1d467746837a5cadc037
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Release notes:
https://github.com/odoo/owl/releases/tag/v2.0.0-beta-11
Details:
[FIX] fix some issues with t-out with falsy values, and with default values
[REF] app: slightly simplify the create component path
[IMP] compiler: add support for binary operators
[IMP] add support for t-call-context directive
[FIX] properly get component reference instead of context
[FIX] blockdom: fix crash when class object key has leading spaces
closesodoo/odoo#94798
X-original-commit: 4dc5ff6569f658ccf525e9078b8a776ca5c0f159
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce (in slow 3G):
- Go to the website app,
- The "Optimize SEO" menu is not available while the iframe is loading,
- Wait for the iframe to be laoded,
- Go to another app (discuss for example),
- Go back on the website,
- This time, the "Optimize SEO" menu is already available,
- Click on it, it crashes.
The website metadata from the website service were not correctly cleaned
when leaving the website_preview client action. When going a second time
on the client action, the "Optimize SEO" isDisplayed method was based on
outdated metadata.
This commit resets them when the pageDocument is set to null (when
leaving the client action).
task-2687506
closesodoo/odoo#94631
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes a race condition happening when clicking on the "Link
Tracker" menu of the website, when the website_preview client action's
iframe is not loaded yet.
That menu uses the iframe's contentWindow.location (taking it from the
website service), which was not set before the "load" event of the
iframe.
With this commit, the contentWindow is set at the website service level
when setting the pageDocument, as it can be taken from it
(document.defaultView), and the link tracker is displayed only when
there is a contentWindow at the website service level.
task-2687506
Part-of: odoo/odoo#94631
This commit warns company from countries not supported by Stripe to
activate Stripe from the settings page.
This commit also enable the Stripe Connect Onboarding from the website
settings page.
task-2789227
closesodoo/odoo#87562
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Ensure the link are visible enough in the editor.
task-2855712
closesodoo/odoo#94760
X-original-commit: 5d598e4269431222ae28ac2196ff6f1f45466734
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
*: im_livechat, website_livechat.
The autoOpenDiscuss parameter was used but is deprecated for a while now.
This PR removes it.
closesodoo/odoo#94716
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the `major_amount` was rounded before the conversion
to the minor currency unit, leading to an approximation error when
multiplying a float.
After this commit, the conversion of the `major_ amount` to the minor
currency unit is done before the rounding, ensuring no float approximation.
closesodoo/odoo#94698
X-original-commit: 4a4e0129c09e2db11c46a90a07704dc37cb4fb20
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
1- install sales
2- allow warnings on sale orders
3- set a warning w with multiple lines on
sale order on customer c
4- try to add c to a sale order
5- w will be shown in one line
Bug:
the html is escaped and the proper styling is missing
Fix:
add the proper style
OPW-2847660
closesodoo/odoo#94730
X-original-commit: 36546f39ca44f6d5691e3b1d8a7d1eb2da4a7b51
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Purpose
=======
When a public user fill a form on Website (e.g. /contactus), an email
will be sent. The email filled in the form will be used as the "email
from", but if no mail server match this email address it will be
encapsulated into "`notifications@mycompany.com`" (see odoo/odoo#61853).
Even though the email is still present in the "Reply-To" header, we
want to add it at the end of the email, so the receiver has this
information easily.
Task-2833093
closesodoo/odoo#94728
X-original-commit: a57944cc387a0b2f0eb6450a14a14e149c720181
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Current behavior:
When using IoT-scale device to determine the weight of a product in PoS
if the product was tracked by lot the weight would always go back to 1
Steps to reproduce:
- Have PoS installed and activate PoS IoT
- To simulate the IoT you can modify the weight on this line
https://github.com/odoo/odoo/blob/ff58fb0fb588092f1d02500cd000d20a3f8b67b7/addons/point_of_sale/static/src/js/Screens/ProductScreen/ProductScreen.js#L140
(e.g. change weight with 5)
- Create a product with UoM in Kg, and tracked by lots
- Start PoS session and add the new product to the order
- The quantity is not correct
opw-2862429
closesodoo/odoo#94727
X-original-commit: 6b37b0e3a0a82e8bbc51993d84257e0d71ab961d
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
* Use div name/id instead of dummy classes for xpath references
* Use clear variable name (picking instead of i in the t-foreach)
* Use t-elif/t-else when useful to reduce python evaluations of
exclusive boolean values
* clean xml indentation
closesodoo/odoo#94704
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In base, when the group "group_partner_manager" is created, user_root &
user_admin are already specified as group users.
Therefore, it's useless to add them again in the data of the crm & sales
modules.
Part-of: odoo/odoo#94704
Default value for attachment_ids / tokens is None. However a check method consider those
as lists and check their length. When calling chatter_post without giving at least a void
list there is therefore a crash that can be easily avoided.
closesodoo/odoo#94695
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Julien Mougenot