This dashboard depends on the website dashboard which is to be re-done
in OWL. Instead of keeping this dashboard as a separate component, it
will be re-done in the Dashboard App (see task-3222991).
task-3164163
Part-of: odoo/odoo#112819
When the cart has a zero amount (because of pricelist, coupons, ...),
providers are not loaded nor displayed.
Furthermore, if there is no need for delivery (because the cart only
contains services), delivery carriers logic is not loaded either.
In this case, without carriers nor providers managing the disabling/enabling
of the confirmation button (o_payment_submit_button), the base logic handling
the T&C checkbox didn't properly enable the button when it should have.
Introduced by 608e90e998, already fixed
for payment form by 04059d09dfd7dc57a5c86c842d6fea300e1441aa
opw-3418472
closesodoo/odoo#127950
X-original-commit: d3bcf03adb93d2727ed81e1b9ffe0a2bbc5707b0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When you add items in the cart it always show the number of available left in stock of the previous state for example :
1- cart is empty it shows 20 items
2- add one into cart - it shows 20 items left in stock (should be 19)
3- add another one into cart - it show 19 items left in stock (should be 18)
Steps to reproduce the error :
1 - Go to one of the product and make sure that it has some available quantity
2 - Go to sale configuration on the product and remove "out-of-stock : continue selling" and add show available qty only if below 5000 for example
3 - Go the web page of the product and try to add some items into the cart you will see that the stock message is wrong
The origin of the problem is that when we have optional products activated , it will launch a product configurator modal. After posting the update in the database there is no call to the function that updates the stock message.
opw-3341377
closesodoo/odoo#126802
X-original-commit: cec84ac8f761b516aef61e2721b7d619834be730
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
If a cart has multiple lines with the same product (custom/no_variant attributes),
opening the reordering wizard on the portal would fail, because the key used in
foreach would be the same for multiple iterations.
closesodoo/odoo#126151
X-original-commit: 80bce88e73770debe64fb401003dac35cb4f6785
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
New "Re-order from portal" feature for e-commerce orders was not
considering specified no_variant & custom information on the order at all.
This commit makes sure the information is correctly forwarded to the cart,
ensuring the reordered products are the same as the ones previously ordered.
opw-3380312
X-original-commit: 9e774cf88398b7ffc701c4adf44451e39963db08
Part-of: odoo/odoo#126151
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Commit 91d0e9c645 made sure that excluded
combination did not appear in /shop search results, but it significantly
slowed down searches, even in databases without exclusions.
Since the excluded combinations cannot be added to the cart (and the
original feedback did not come from an effective ticket), we believe
the gain is not worth the cost.
This commit reverts that change.
Task-3326948
closesodoo/odoo#125722
X-original-commit: 3082ac99dc195a89e1299be73ef149f40231f86e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
-------------------
- install website_sale and delivery_sendcloud module;
- create a shipping method (use Sendcloud provider);
- configure the integration with
"Mondial Relay Point Relais International 1-2kg";
- configure option with shipping rule and use location;
- on website create a new quotation with the pubic user;
- process the checkout;
(Check in backend the shipping weight)
- fill City and Zip Code fields with correct value
(example: Paris | 75011)
(- configure the company's country)
Issue:
------
[1.] If the shipping method is the only one, the locations are not displayed.
[2.] The delivery address is not the address of the chosen location.
Cause:
------
[2.] The method `update_eshop_carrier` is retriggered after update the `access_point_address` field.
The `access_point_address` is reset.
Solution:
---------
[1.] Show the option to choose a location if we only have one delivery method
(we are certain that the options should be displayed).
[2.] Use a parameter in the post request to instruct
not to reset the `access_point_address` field.
opw-3326139
closesodoo/odoo#125647
X-original-commit: 677bff31d3acdd05fff6567b693de78cff256ea2
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows
In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.
This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.
This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.
In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.
closesodoo/odoo#125284
X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
With Jquery.data, you can set everything as value (array, object,
string, etc) wich is confusing. This commit fix the function that check
if the button is ready. It didn't work because the data declared
in this.$submitButton is not a boolean but an object.
Bug was introduced in PR 118012
commit : a6b46fdfdb855
closesodoo/odoo#124795
X-original-commit: 04059d09dfd7dc57a5c86c842d6fea300e1441aa
Signed-off-by: Géry Debongnie <ged@odoo.com>
Current behaviour:
In the context that a variant is being archived after the removal of
one of it's attribute lines, on the e-commerce product's page of
said product some of the attribute values are disabled because they
were part of the archived variant.
Expected behaviour:
Archiving a variant due to removal of an attribute line shouldn't
disable the selection of the other attributes on the e-commerce
product's page of the product, since the variant can never be
reconstituted (the current selection of attributes lines is `X-1`,
where `X` is the number of attribute lines of the archived variant).
Steps to reproduce:
- Install eCommerce,
- Create a product with 2 attribute lines and add values A1,A2 and
B1,B2 respectively, 4 variants should be created (cross-product).
- Go on the e-commerce product's page of the product, add the
variant A2,B1 to the cart
- Go in the backend, delete attribute line (B1,B2), from the product
template
- Go back on the e-commerce product's page, the option with A2 is
disabled.
Reason for the problem:
When deleting an attribute line from a `product.template`, if one of
the variant is being used somewhere (in our case as a `sale.order.
line` of the cart), it is archived instead of deleted. This means
that when loading the page of the product with send the attribute
values of the archived products, so we can disable the selection of
the attributes that would make the archived variant. Since A2 is
part of the variant A2,B1 that was archived, we disable the
selection for A2, without taking into account that we don't have the
same number of attributes than the archived variant and it is
impossible to make the archived variant from the e-commerce
product's page.
Fix:
Restrain the condition that checks for which attributes to disable.
We make sure that we have *any* common part of the selection to the
archived variant, and we also make sure the count of the attributes
for the product is the same as the archived variant we are checking
against.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3329225
closesodoo/odoo#124536
X-original-commit: 411441861a3242fddce5ffd02b09cbc5556aef90
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
When the product sold has a zero price,
it is possible to click the "Confirm Order"
button several times.
This will send several confirmation emails.
Cause:
Because the price is zero,
we do not have a widget that handles
the `disabled` attribute of the button.
This is handled by a widget
when we have the `o_payment_checkout` form,
but it is not the case when
selling a zero price product.
Solution:
Change the attribute of the submit
button when submitting the form to prevent
multiple click.
opw-3246935
closesodoo/odoo#124519
X-original-commit: 53c6ebfdf7c5acb5103bf9ef5cb7c12f92ceefb9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Entering a value greater than that allowed by a 32-bit integer raises an
error
Steps to reproduce:
1. Install eCommerce
2. Open the website and go to the 'Shop' page
3. Open the editor and click on any product in the grid
4. Set the value of the 'Number Of Products' to an integer greater than
2147483647
5. An error is raised
Solution:
Limit the number of product per page to 10000. This will have the effect
of avoiding the `NumericValueOutOfRange` error but will also prevent the
user to load too much products at once to avoid a timeout.
opw-3226154
closesodoo/odoo#124158
X-original-commit: f620e95b5e459551f881a9aec2bc75b45b9d354e
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit:
- Unifies the SCSS code for the off canvas filters used in
website_sale and website_crm_partner_assign
- Removes the custom width of 80% on small devices that made it
possible for the user to click outside of the `.offcanvas` to close it
- Adds a close button in the website_sale `offcanvas` as the default
`.offcanvas` width is 100% on small devices and the user needs an exit
button as he can't click outside of the canvas anymore
task-3083706
Part-of: odoo/odoo#109752
As it holds full HTML documents, mail.mail often encounters issues with
the html editor.
We piggy-back off the intoduction of the switching
behavior between code-view and readonly-view behavior introduced in
a5c0085ce91570c6c961e3293dfe50f4faba6043
The 'sandboxed preview' mode can now be enabled with an option
and will ensure all content can only be viewed in a sandboxed iframe
or in the code editor.
This re-introduces editing, which was mistakenly fully disabled in the
usability fix that introduced body_content here:
5055b374c3bac0126f441dad61afd7e0b68b1370
Some tests are added to ensure the key points of this commit remain
the same. Tests are re-ordered alphabetically to match the order
of execution, making debugging easier.
task-3255777
closesodoo/odoo#121976
X-original-commit: 062569ef042f3b01044c5e4cdbd8b71e96bfd39d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
Before this commit : The library underscore.js and
underscore.string.js were used in the ODOO solution.
After this commit : Every usages of a function from
underscore.js lib has been replaced with native javascript.
The goal is to remove all usages of underscore.js and to
not use anymore this library in ODOO.
---
TaskId : 3246238
closesodoo/odoo#120437
Signed-off-by: Géry Debongnie <ged@odoo.com>
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
On the ecommerce, we want the pricelist to be adapted
to the user who is connected.
If no user is logged in, the 'Public Pricelist' is used.
To determine the pricelist that will be used (by default):
https://github.com/odoo/odoo/blob/a3169ede4f609b56c83da04756d20b1c7a07251f/addons/website_sale/controllers/main.py#L350-L354
Therefore, if we have been to the shop as a 'Public user' and we decide to log in,
we already have a pricelist in `request.session.get('website_sale_current_pl')`.
So we have to clear the pricelist when we connect to determine the new pricelist
of the user.
opw-3228998
closesodoo/odoo#121074
X-original-commit: 71b2d817df93f0cc8c1f5c424a3555bcadf33b2d
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce:
- install website_sale;
- install a delivery mode (or create it);
- add a cost to it;
- publish the shipping method;
- make the purchase flow and modify the shipping method.
Issue:
The total price is not updated.
Cause:
`querySelector` returns the first element
that matches one or more selectors.
In this case, it is not the one that is expected.
Solution:
Use `querySelectorAll` to update the price
of all items designated by the selector.
Remark:
An other problem appears with the fix of the first problem
when using a gift card to pay (for example).
Indeed, the latter did not appear as we did not update
the prices correctly.
By updating the programs and rewards, the amounts
have been recalculated on the sale order.
It is necessary to transmit this information to the frontend.
opw-3277204
closesodoo/odoo#120744
X-original-commit: 460f90a59218202c1f77405609fadfc2640b2f9c
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
Steps:
- In eCommerce activate Filter by prices and Attributes & variants filters
- select one attribute with >1 item (e.g. aluminum legs)
- put a price limit.
- the attribute filter is removed.
The commit will prevent the removal of the 'variants attribute filter'
when an attempt is made to apply a price range.
task-3101343
closesodoo/odoo#120692
X-original-commit: a295faafd059b9aa38b759f7ce4ef7f3108464c4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Since commit [1], when we are in the `/shop/cart` page and if a language
selector is in the header, a cart popover also appears when hovering the
languages. This happens because the `websiteSaleCartLink` widget
selector also targets the cart links inside the language buttons.
This commit solves this issue by excluding the language selectors from
this widget selector.
[1]: https://github.com/odoo/odoo/commit/ecefa679b224ce0e4a5a7e91ce28936321132d9c
opw-3288727
closesodoo/odoo#119887
X-original-commit: bdfceb8ed274cd343d273c0a7f9bbb513617a0b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when hovering the shopping cart in the "Boxed" and
"Centered Logo" header templates, the cart popover was not appearing.
This happened because the `websiteSaleCartLink` public widget was never
started with these templates and so, hovering the cart had no effect.
This is due to this widget selector which targeted a cart link located
inside an element with id `#top_menu`, which is not the case in these
templates where the cart link is located outside of it.
This commit fixes this widget selector, in order for the cart link to be
reachable in all header templates.
opw-3267114
closesodoo/odoo#119277
X-original-commit: ecefa679b224ce0e4a5a7e91ce28936321132d9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, `website_sale` uses the same logic as `sale` to show the
product variant configuration.
This commit aims to separate this logic and let each module handle its
own product variant configuration.
task-3056806
Part-of: odoo/odoo#106511
Replaced _.each() functions (average 235 occurences)
Description of the refactoring this PR addresses:
Current behavior before PR:
There are underscore.js function enumerated above used in odoo.
Desired behavior after PR is merged:
These functions has been replaced by native javascript
prototypes/methods/functions.
TaskId : 3246238
closesodoo/odoo#118565
Signed-off-by: Georis François (fge) <fge@odoo.com>
Steps to reproduce:
- install website_sale;
- with web editor add a language selector to the top bar menu;
- go to the page '/shop/cart';
- click on the cart.
Issue:
A traceback appears.
Cause:
We use the property of a HTML element without checking its presence.
opw-3246545
closesodoo/odoo#117966
X-original-commit: e6829c38ff3fc0139583be94bf6f86c9acaab8fa
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: website_blog,website_event,website_forum,website_hr_recruitment,
website_livechat,website_sale,website_slides
Prior to this commit, elements inside the New+ modal had a `isDisplayed`
property that was meant to be changed by the patches done by each
module. Unfortunately, this was forgotten in the refactor done in [1]
and more precisely when the component was introduced in [2].
This commit fixes that by checking the access rights of the user on each
individual model used on the create form.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/ca2e143d54622d598201826a2cd669bad64b205d
opw-3198700
closesodoo/odoo#117206
X-original-commit: 58704cb7615addd7d40291431e05a894776320d8
Related: odoo/enterprise#39066
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Move the test because the field `optional_product_ids` is defined
in the module "product_configurator".
Therefore, if the test is in "website_sale"
and is run without the "product_configurator" module there is an error.
We move the test to the "bridge" module
between "website_sale" and "product_configurator".
opw-3140859
closesodoo/odoo#116742
X-original-commit: 4f4d6c1422b5b258fc5176a0f341b47c0fc1e963
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Previously:
The displaying of the technical menu email would be cut
if you had a zoom of > than 100% on your browser
Currently:
It allows to see the whole content of the message without scrolling.
closesodoo/odoo#116124
X-original-commit: 5055b374c3bac0126f441dad61afd7e0b68b1370
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>
==== Purpose ====
There is an issue with the `/@/` symbol website is using to display a
page in the backend: if someone copy paste a link with `/@/` in it and
send it in an email, some mail client will block those mails.
It was reported by our internal team, after feedback from some sales
persons.
Office 365 was incriminated (not the outlook.com web platform). While we
couldn't reproduce the issue, it was decided by the hierarchy to get rid
of it as it was judged impossible to educate our sales to not send such
links.
It's probably a good decision as:
- `@` in URL are usually used for HTTP Authorization:
`http://username:password@example.com`
Link [1] seems to mention that some mail client will not implement
correctly the URL check to see if the `@` is problematic and will
simply block mails having links containing `@`.
- The tradeoff of removing it is impacting dev/tech people, not the end
user (except for F5, see below).
==== Technical ====
Before this commit and since commit [2] the following behaviors were
introduced:
1. a `/@/` prefix was added visually in the URL bar of the browser when
accessing the website app (previewing your website in the backend) to
differentiate it from the regular website/frontend URL
2. the possibility to type yourself `/@/` in the URL to access a website
page in the backend app
It was improving the following pain point:
A. On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
B. When the user edited the URL (Like removing `/shop` and typing
`/jobs` instead, he would land on the frontend version too.
C. Impossible to directly go to the backend version of the website.
This commit is now reverting point 1. while keeping the possibility of
point 2.
It means that while you can still reach directly your page in the
backend, the backend URL part `/@/` won't be kept.
About the mentioned point above:
A. This pain point will be back
B. This one too but workaround possible: need to edit the URL but also
need to now add the `/@/`
C. This one will still be "fixed" as `/@/` still reachable.
While it seems to be decreasing the UX, it actually is an acceptable
tradeoff as:
- It mostly impacts dev/tech people, lambda end user don't play with
URLs (low risk)
- It will prevent their mail to be blocked (high value)
--------------
Finally, note that in the meantime commit [3] was introduced which
relied on this `/@/` presence. This had to be adapted.
[1]: https://www.malwarebytes.com/blog/news/2022/05/long-lost-symbol-gets-new-life-obscuring-malicious-urls
[2]: https://github.com/odoo/odoo/commit/030d3cb10ee79aa1f010134578f4bcf65a1cfcde
[3]: https://github.com/odoo/odoo/commit/a0b3499d348d252c3abd48154e1fd8dd545c7504closesodoo/odoo#116100
X-original-commit: b01337710b5fde995a184e442f48b687cd17967a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
It's currently impossible to set fixed delivery costs in eCommerce
without installing Inventory. This is a problem for one-app free
instances on our SaaS, which would need to pay for a feature that
should be part of the basic eCommerce features bundle.
This commit makes it possible to define fixed-cost delivery methods in
eCommerce without installing Inventory by adding a direct dependency of
`website_sale` on `delivery`. The bridge between those two modules is
therefore included in the former.
Part-of: odoo/odoo#110686
Since [the merge of the frontend into the backend] and more precisely
since [this commit], clicks on some elements makes the user switch from
the backend view to the frontend view.
Steps to reproduce (just an example):
- Go to /blog from the backend (/@/blog)
- Click on a tag (eg: adventure)
=> users are redirected to the frontend view, we do not want that. This
commit makes the user stay in the backend. For some scenarios (like the
one above), we create a fake form and submit it. The forms have a target
attribute that specifies where the form response should be displayed.
This commit set back the default value for the target attribute when a
user clicks on a blog tag, a course tag, the pager, ... so that the
response is displayed in the current context (the iframe when the user
is in the backend).
Note that [this commit] introduced the target attribute change to fix
two issues:
1. The opening of the payment gateways in the iframe.
2. The create page from a 404 page in the backend.
After [this other commit] has been merged, to prevent the first issue so
here we just remove the target attribute change except for the case of
the second issue.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this commit]: https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64
[this other commit]: https://github.com/odoo/odoo/commit/3a32b9e1efa6277b345dc9239334680651690df7
task-3054970
closesodoo/odoo#114056
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- create an attribute with "never" as the mode of creation;
- create a product with this attribute;
- add an optional products to this product;
- go to ecommerce and add this product to the cart;
- take care to change the value of the attribute;
- click on the "Proceed to Checkout" button.
Note: optional product allows to open the modal window on the ecommerce
Issue:
In the cart, the selected attributes are the default ones.
Cause:
We will look for the information in the modal window template.
Unfortunately, the `getCustomVariantValues` and `getNoVariantAttributeValues`
functions are not adapted to the modal window template.
Therefore, the information is not found.
Solution:
As the information is searched on the template of the modal window,
it is necessary to maintain the information on it.
opw-3140859
closesodoo/odoo#114753
X-original-commit: cc0bcb15ec88dd67fd9225c6decc3451b4df4708
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the accounting module had a setting on the selection of taxes used by the sales, purchase, website_sale, ... modules. In addition, the website_sale module had the same setting related to the accounting one.
This PR isolates the tax selection parameter in the website_sale module, and instead of using the tax selection, the accounting module will use rounding method (round per line, round globally).
Selecting one of the two will change the display of all account_move or other view using the tax selection setting.
Display changes:
In round per line, a column tax excluded will always be displayed while a column tax included will be in optional hide.
On the other hand, in the round globally, only the tax excluded columns will be available.
closesodoo/odoo#99209
Task-id: 2954332
Related: odoo/upgrade#3826
Related: odoo/enterprise#30853
Signed-off-by: William André (wan) <wan@odoo.com>
When selecting the content of a tab with Chrome, if the selection
reaches the end of the tab content and there is additional content after
the Tabs snippet, the selected range also includes the next inactive
tabs that are hidden. Because of this, when replacing that selection,
the next inactive tabs are removed, and the Tabs snippet is corrupted.
This commit avoids this by including the `.tab-pane`s in the read-only
areas while including its `.oe_structure` in the content-editable areas.
This makes the selection adjustment mechanism stop within the active
tab pane.
Steps to reproduce:
- Use Chrome.
- Drop two Tabs blocks inside a web page.
- Select the first tab of the first one.
- Select the last word, including the dot. (Double-click the word and
drag beyond the dot before releasing the mouse button.)
- Change the selected text's color.
=> The content of the second and third tab also had the chosen color.
- Select the text in the first tab with a triple click.
- Type something to replace the text.
=> The content of the second and third tab were removed and clicking
on the tab's header did therefore not reach them anymore.
opw-3117305
closesodoo/odoo#113624
X-original-commit: fd57dae13179c286da99749e77a3b26efd2f73f2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As the tour `shop_editor` is very small, it finishes before the editor
itself is fully loaded.
As a consequence, some threads are remaining on the server side and can
lead to a complete failure of the test.
This seems to particularly affects builds on Bookwork with werkzeug
2.2.2 and python 3.11 as it leads to werkzeug requests timeout.
With this commit, a step is added at the beginning of the test to ensure
that the editor is loaded before beginning the test by itself.
closesodoo/odoo#112698
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: website_sale
During the big "website-in-backend" refactoring, [1] and [2] were made
to add the "edit-in-backend" and publish buttons in the systray. At the
same time, the information about if the main object of the iframe is
available to "edit-in-backend" / is published was added on the loaded
iframe's html element (as was already the information about what the
main object is).
The problem is that [1] + [2] were merged around the same time as [3]
which decided to put the existing data addition on the html element...
in a t-if. [1] and [2] ended up adding the new information only if the
user is a designer, while it is actually needed as restricted editor
users. As a result: the publish and "edit-in-backend" buttons did not
appear anymore for restricted editor users.
At the same time, [3] seems wrong on its own, as it moved some
information in the conditional block although we wanted that information
to be available even for visitors (especially, the main object which is
for example used by the product snippet*). This is fixed by this
commit too.
* Steps to reproduce:
- As a restricted editor, go to /shop in the backend iframe
- Click on a category at the top
- Edit
- Add a "Products" snippet in the category-related area
- Click on it and choose "Current" as the value for the category
=> Crash. That crash actually also occurs as a visitor on page load if
such a snippet was saved by an admin first (but the crash in that case
is silent).
Note that the "seo-object" info is not needed by public users but was
restored as a public data as it was the case in 15.0. It might make
sense to some custo. However, the "oe-company-name" info, which was
public in 15.0, is kept shown for designers only as it seems to be dead
code in 16.0 (will be removed later on in master).
Unfortunately, no stable fix can really be made to solve this issue:
this commit had to modify the existing `website.layout` XML. So to solve
this issue in existing databases, you either have to patch the view
accordingly or update the website app. That should be ok, considering
that the only real problem is that some options cannot be used as a
restricted editor user.
[1]: https://github.com/odoo/odoo/commit/f260e3c1441b380d0c9f5294d7cadcaad9c90662
[2]: https://github.com/odoo/odoo/commit/028efcbffe1cbaa00fe6a262151c75fda922008d
[3]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
task-3129034
X-original-commit: bfb6d7820c35f3eba3bb760810866350092a16d9
Part-of: odoo/odoo#111289
Arthur Detroux (ard)