In our continued effort to remove legacy code, this commit replaces
usage of the legacy DropMisordered util with the KeepLast util. The legacy
DropMisordered has been removed.
Part-of task-id 3439226
closesodoo/odoo#132559
Related: odoo/enterprise#46027
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In our continued effort to remove legacy code, this commit replaces
usage of the legacy DropPrevious util with the KeepLast util. The legacy
DropPrevious has been removed.
Part-of task-id 3439226
Part-of: odoo/odoo#132559
This commit moves the ZoomOdoo library out of the web module and the
backend bundle (through the common bundle) to the website module (as
it's used by it and its dependent modules).
Part-of: odoo/odoo#130875
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
Steps to reproduce:
- Install website_sale
- Go to website shop in the frontend
- Login, Edit
- Click on 3rd or 4th kanban item
- Push down
Issue:
The item goes to the end of the list instead of moving one element to
the right/down. Pushing an element down searches for the next element
with a higher `website_sequence` and places the current element right
after, by switching their sequence values.
Normally the logic works fine, but the problem arises when the
`website_sale` module is installed, when records with
`website_sequence = NULL` are set to the same default value, namely
10000. Then, when an item with `website_sequence = 10000` is pushed
down, it will skip many items, before finding one with a higher
`website_sequence`.
Solution:
When updating records with `website_sequence = NULL`, assign an unique
sequence to each one. We can set the `website_sequence` relative to the
inverse of the id to ensure that the order on the shopping page remains
the same as it was prior to the fix.
opw-3318867
closesodoo/odoo#131496
X-original-commit: 6d3d64b480928472fe94ed80f8cc983c88b085e8
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
This commit removes the qweb.render method, instead it will use the owl
render engine (renderToString or renderToElement).
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
This commit removes legacy patch/unpatch functions and adapts their use
by using the modern patch. There was also a custom patch function used
in tests which has been replaced too.
closesodoo/odoo#130867
Related: odoo/design-themes#685
Related: odoo/enterprise#45271
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Cause by #105848
opw-3427995
closesodoo/odoo#130732
X-original-commit: af1f23c956f7ccbf11d8d5d512f656901c92ad00
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
* Impose the use of the dedicated tour utils to factorize and harmonize
the way tours behave on the ecommerce.
* Introduce new utils when it seems adequate and useful.
This will reduce incoherences and non determinism in e-commerce tours,
and ease future tasks refactoring the e-commerce design and process
(since we'll be able to restrict most changes to the utils instead of adapting
all the tours one by one).
closesodoo/odoo#130378
Related: odoo/enterprise#44938
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: sale_product_configurator
Enterprise PR: odoo/enterprise#42551
Steps to reproduce:
1. Install website_sale
2. Create product P
- Go to Attributes & Variants tab
- Add a line
- Create and edit attribute "PILL"
- Display Type = Pills
- Add some attribute values
- Save & Close
- Add the attribute values in the list view
- Save the product
3. Go to website product page
Issue:
The pills have a visible radio button inside, requiring users to click
on the radio button to change the variant. In V15, there was no radio
button, and users could click anywhere on the variant container to
change the variant.
The change in behaviour happened because the jquery code for handling
button clicks has changed. In V15 jquery, clicking a button would
trigger a change event, which would then be captured by the owl event
selector `change [data-attribute_exclusions]`, and the
`onChangeVariant` method was called.
In version 16, jQuery no longer triggers a change event when clicking
a button.
Solution:
Hide the radio input visually, then convert the variant text to a
label. When clicking on the label, the corresponding radio input
is checked.
This means that the whole button is not clickable anymore, only the
text.
opw-3185147
closesodoo/odoo#130615
X-original-commit: dc7af6a4c555740b2c2b13efe57cd971e14dc67f
Related: odoo/enterprise#45103
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
As steps are encapsuled in an arrow function from
69a5d8e3ce47238 for steps tour definition to avoid
direct Markup(_t()) interpretation, the same is done
for registerWebsitePreviewTour() of
"odoo/addons/website/static/src/js/tours/tour_utils.js"
in this commit.
This is done in anticipation of the use of
_t() (import from @web/core/l10n/translation) with
registerWebsitePreviewTour().
task-3292454
closesodoo/odoo#130248
Related: odoo/design-themes#678
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
The test test_update_cart_zero_qty was checking the total amount
of the cart, but depending on installed localizations, the taxes
vary and the test can fail.
This commit changes the check to the untaxed amount to make sure
the test only depends on the sales price of the product defined in
the test setup.
closesodoo/odoo#130319
X-original-commit: a2c693795081953ed0ba07bfad210701fcf6f1f0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The default pricelist automatically created for companies if the pricelists
are enabled should (like it was before with the Public Pricelist record in
the data) take precedence over newly created pricelists record.
This can be enforced by creating the default pricelist with a higher priority
(lower sequence).
closesodoo/odoo#130232
X-original-commit: ea1e83514bd6190a516f2cf92f800625876b789e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The tour was using a payment provider that was not installed. This
commit makes sure the test only runs when the payment provider is
installed.
Fixes build error 19829
closesodoo/odoo#130214
X-original-commit: ba75b1c023988e17852821ddaf32163c2e2f9d6e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
*: bus, crm_livechat, crm_mail_plugin, im_livechat, payment, payment_demo,
pos_online_payment, test_discuss_full, test_mail_full, tests, website_livechat,
website_sale.
Several python tests have their own way to make jsonrpc requests. This PR adds a
generic `make_jsonrpc_request` method to the `HttpCase` in order to provide a
generic way to do so.
At the same time, calls to `_open_livechat_channel` are removed in favor of
jsonrpc request to `get_session`. This makes the tests more realistics (some
incoherences were present like passing `country_id` to the open channel method
while the user country id is not set...)
Finally, this will ease the diff in the PR introducing livechat visitors as mail
guests.
part of task-3332628
closesodoo/odoo#130036
Related: odoo/enterprise#44840
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- fix tag filter
- fix product_product view in sales
- fix add to cart animation
- impove product tag view in website_sale and product
closesodoo/odoo#129901
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Issue:
When we activate the terms and conditions,
the button "Pay Now" is not "disabled"
at the first loading of the page.
Cause:
When we update the carriers
(via `_handleCarrierUpdateResult`),
if all conditions are good,
we activate the "Pay Now" button
(via `_setIsPayable`).
We do not take into account
the checkbox terms and conditions.
Solution:
Use payment's `_enableButton` method
to check all the conditions.
Introduced with 0967efaa24
opw-3323938
closesodoo/odoo#129437
X-original-commit: 4217b923cb2ca06710c2f5ac31c4d609390ce4fe
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Setup:
------
1) Install website_sale module
2) Product:
One product with:
- Sales Price: 100
- Customer Taxes: 10% included
3) Fiscal position
Two fiscal positions:
- Country: France - 10% included --> 20% excluded
- Country: Netherlands - 10% included --> 15% included
Steps to reproduce:
-------------------
- without being logged in, go to ecommerce;
- add the produt to cart;
without information on the tax position, we have:
90.91 + 9.09 = 100 --> this is correct
- process checkout;
- Enter an address with the country France;
France:
90.91 + 18.18 = 109.09 --> this is correct
(100 : (1 + 10%)) * (1 + 20%) = 109.09
- edit the billing address;
- use the country Netherlands;
Netherlands:
104.55 + 20.91 = 125.46 --> this is wrong
instead of:
90.91 + 13.64 = 104.55
(100 : (1 + 10%)) * (1 + 15%) = 104.55
(This is just one example)
Issue:
------
There is inconsistency in the application
of taxes according to tax position.
Cause:
------
To calculate the product's price unit, we apply
tax position mapping via the
`_get_tax_included_unit_price` method.
Modifying the `price_unit` field in the
sale order line will trigger the
compute method `_compute_amount`.
This recalculates the amounts,
but without taking into
account the tax position mapping.
We therefore use a value for the `price_unit`
field which is not in line with the taxes.
Solution:
---------
Recompute sales order line taxes
when a change in fiscal position is detected.
opw-3318971
closesodoo/odoo#129440
X-original-commit: cdb9819b0e199f95d489e8cfe4217cf6de6362b3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
use product tags to display information as color/image on the product
page, enable filtering by tags, add tags to specification/comparison
table. Remove the link between ribbons and tags because there is no use
as we are able to show the tags on the page, add ribbon to
product.product
task-3299538
closesodoo/odoo#124299
Related: odoo/upgrade#4824
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The goal of this commit is to remove all dependency to legacy in the
wysiwyg because the wysiwyg has to be loaded on a lot of form view
(through the html_field).
To remove the dependencies, all the legacy widget that the wysiwyg
uses had to be converted to owl. In order to finish the PR faster,
only a partial conversion of the widgets is done, changing only the
part of the code that was necessary for it to work instead of
rewriting the whole widget from scratch. Another pass should be done
to convert all those widgets to fully embrace the owl paradigm.
task-3175256
Part-of: odoo/odoo#118966
Before this commit, only the cross icon "x" top right of the popup would
be able to properly close the popup and set a cookie to prevent that
popup to open again later.
There is no way through the UI to make a button in the popup do the same
behavior.
This commit now add this behavior to any `.btn-primary` element inside
the popup, except a few ones like the newsletter input group button and
the website form submit one.
Note that we have a way in stable to do that, but it's through code.
People have to add the `js_close_popup` class to the button. This class
is there for this reason, but it's obviously limited to tech people
only or our support.
task-3377306
opw-3328135
closesodoo/odoo#124432
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Prveiously the "Edit in Website Builder" button was not shown for terms
and conditions if website is installed, it was shown only if the
website_sale module was installed. This commit fixes that.
task-3342876
closesodoo/odoo#127735
X-original-commit: 079704a2a5ed42ed774318fd8520d108f17222bd
Related: odoo/upgrade#4912
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behaviour:
After archiving the public pricelist (14.0 to 16.1,
as 16.2 does no longer have a public pricelist),
when creating a new pricelist, it replaces the previous
pricelist with all partners.
1 Second pricelist
2 First pricelist
Expected behaviour:
New pricelists should go after the previous one
1 First pricelist
2 Second pricelist
Steps to reproduce:
1. Go to settings, activate Pricelists
2. Head over to Sales->Products->Pricelists
3. If applicable, archive the public pricelist
4. Create a new pricelist (named 'First')
5. Create another pricelist (named 'Second')
6. Go to Contacts, select any contact
7. In Sales & Purchase see Pricelist
8. Second pricelist is set, should be First
Cause of the issue:
_order is set to "sequence asc, id desc"
Since new pricelists have a sequence of 16 by default,
new pricelists (with a higher id) get placed first.
Fix:
New pricelists without a sequence number get sequenced based on the
highest sequence number in existing pricelists
opw-3282880
closesodoo/odoo#121441
Related: odoo/enterprise#43591
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
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
With the new website header templates, a search bar will be available
in the header. To avoid two search bars in the page add an option to
remove the search bar in the /shop page.
task-3302735
closesodoo/odoo#121391
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When no payment provider is active, admin users should see the 'Activate
Stripe' button on the checkout page, allowing them to configure Stripe
faster.
This commit also disables the provider 'Pay in store when picking the
product' in the demo data to improve the testing experience of the
eCommerce settings on runbot.
task-3235154
closesodoo/odoo#121138
Related: odoo/enterprise#40934
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
- set shipping methods country to mexico (empty states)
- fill an order on website on check out select seprate shipping/billing
- on billing set country as US
- on shipping the only country avialable is mexico
- avialable states are the ones from the US not mexico
Bug:
the states are set from the country of the customer even though it isn't
an option on any carrier.
bug was introduced by this commit[1]
Fix:
revert the mentioned commit(1) since a new commit[2] was introduced that
correctly handles that use case too
[1]:https://github.com/odoo/odoo/commit/d59fe9c58c2dcc2bf6613adb7ac3662597b50496
[2]:https://github.com/odoo/odoo/commit/297641da69982d6c76bd591296636b479cabf657
opw-3230361
closesodoo/odoo#128349
X-original-commit: c59bc765f186858bffb642987cd88fcb80fe262a
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Specify explicit route for each ,, line
This is part of task 3230280 where global ir.model.access will be
forbidden.
The goal is to make access to public/portal explicit. Too often,
global access was granted with only employees in mind.
Remove ,,0,0,0,0 lines
mail:
employee already had read access to mail.group
still needed to subtypes as in ir.rule domain
mail_group: employee already had read access
pos_mercury: only needed for employees
membership:
move public access for website_membership as needed in the controllers
website_customer: employee already had read access
website_event_booth: no need for category
website_event_exhibitor: retrieved in sudo
website_event_track: not needed for location
Part-of: odoo/odoo#125216
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>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
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>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Reproduction:
1. Install Event, Sales, Webiste
2. Login as Admin, go to Website -> Go to website -> Events
3. Click the Open wood event, Register, buy one VIP ticket
4. In Address step, Edit the billing address, change the name to “Test
Name”, click next
5. The user name “Mitchell Admin” is changed to “Test Name”, we
shouldn’t be able to change the info
Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
we use the can_edit_vat to check if we have existing invoice(s) or
SO(s). However, we should block the route that an employee changes the
billing address when placing an order. If they are placing an order for
external people, it should be done from the back end.
Fix: add an extra error case when it's an employee trying to change the
name or email address when editing billing address. This is the case
when an employee tries to order for external people. They should do it
from the back end. They can still buy for themselves without changing
the billing address. Also added translation in pot. Edited the test for
editing address of log in user, added tests for portal user. Reformat
the invoice exsits check for name change to have better readability
The adding of can_edit_vat:
https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085
Related fix to block the name change:
https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
A patch to not block the checkout process when name is not set:
https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394
opw-3126325
closesodoo/odoo#126261
X-original-commit: 972c55bf76f4c5f1b1bedec4a77ddaeac8be1483
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@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>
Jorge Pinna Puissant