Prior to this commit, the patches done by `account_portal.js` and
`sale_portal.js` were done without any import.
This means that the widget it modifies (PortalHomeCounters) might not
already be loaded in the registry. This could lead to some issue later.
This commit uses an "import" statement on the module that defines
PortalHomeCounters to ensure that it is present in the registry.
task-3249625
closesodoo/odoo#127371
X-original-commit: 7937dbec9699e7d0f68450c469c9b742446303eb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `sol_product_many2one` field is a sub many2one field that should
open the proper configuration system, such as the product configurator.
Before this commit, when inputting some data, then clicking on another
notebook tab, we would often see a crash, because the field has been
destroyed (since it is no longer in the current tab) and it tries to
open the configurator, which requires rpcs.
It is usually a problem when a destroyed component tries to perform some
work. Note that it happens at creation and update. Also, the field
overrides some many2one methods that display confirmation dialog. To fix
this, this commit simplifies the field by only calling the configuration
methods when its value has changed. This is a different strategy that
does not interfere with the many2one basic features. Also, it does not
crash since it will only call the configuration methods on patched, so
it is guaranteed to be alive.
It is certainly not a complete solution, since we should probably move the
code somewhere else not in a field widget, but this would require a
redesign of the code, so it is not appropriate in a bug fix anyway.
Note that the tour had to be adapted, since now the methods
_onProductUpdate/_onProductTemplateUpdate are now called in an effect
(so after a render), which is slightly later than before. But the tour
would click on confirm even before the product update code was executed,
which means that the product was not properly configurated.
This is clearly a concurrency problem: the product configuration code
should be properly coordinated with the basic model, but doing so is a
significative change. Also, in practice, it is not worse than before
this commit.
opw 3178297
closesodoo/odoo#127048
X-original-commit: de7a6f5f3d83356eb02f8fc25b4a0b8aabb946b3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@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
*: 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>
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>
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
Currently, Fields Sales are struggling to create quotations or sale
orders directly from the customer place. One of the issues is that it
is not easy to quickly add products to the SO. Products must be added
one by one and, in mobile, it requires completing a form with
quantities, ... for each new line.
This commit introduces a catalog view that allows users to select
products in a faster and easier way than before, both in desktop and
mobile view.
Task - 3062080
closesodoo/odoo#106382
Related: odoo/enterprise#37915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: chevalierv <vcr@odoo.com>
When applying a discount to the first SO line, a pop-up appears asking
if the user wants to apply it on every line of the SO.
This commit adds a cancel button for a better UX.
task-3300071
closesodoo/odoo#121053
Signed-off-by: Vallaeys Valentin (vava) <vava@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>
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@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>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@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>
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>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the product configurator is opened, the focus is always on the
custom value input, which may scroll down the configurator and make the
user miss attributes
Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
Configurator and save
3. Go to Sales > Products > Products and open product 'Cabinet with
Doors'
4. Go to the 'Attributes & Variants' tab and create and edit an
attribute 'Custom'
5. Add a value 'Notes' and check 'Is custom value' and save
6. Add the value to the product and save
7. Open product 'Customizable Desk', in the 'Sales' tab, add 'Cabinet
with Doors' to the Optional Products and save
8. Create a new quotation and add product 'Customizable Desk'
9. The product configurator opens up with the focus on the 'Custom'
attribute input, if the window has a small height, it scrolls down to
that input
Solution:
Remove the focus on the custom value input
Problem:
The focus was made on the input of custom values
opw-3057390
closesodoo/odoo#113301
X-original-commit: dd3e5be00cc4e3408d90abb3923b6658fb1d3073
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Following up https://github.com/odoo/odoo/pull/112692 that avoided the use
of the 'Number' javascript function in the 'product_discount_field' widget, the
call to that function was left in the code. It is useless and can be removed
since the value of the new field used, the property field 'props.value', is
already a float.
closesodoo/odoo#112891
X-original-commit: fb8b217f8bd2323d33bbeb949f35cd1620557960
Signed-off-by: Victor Feyens (vfe) <vfe@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>
When manually setting a discount on the first line of a sale order having more than 3 displayed lines, the product_discount_field widget prompts the user if he would like to apply the same discount to all the lines.
This fails to apply when the localization uses a comma as decimal separator instead of a dot or uses a digit grouping symbol. This is because the widget calls the JS function Number() on the string that was entered by the user in the discount field, after it was formatted according to the localization.
Taking the number 1500 as an example, different cases are:
- Number("1500.0") gives 1500
- Number("1500,0") gives 'NaN'
- Number("1,500.0") gives 'NaN'
- Number("1.500,0") gives 'NaN'
This result is then used to apply the discount on the remaining lines of the sale orders. Using 'NaN' will result in a 0% discount.
The use of Number() can be avoided by using the property field 'value' of the product_discount_field widget.
opw-3127690
closesodoo/odoo#112734
Forward-port-of: odoo/odoo#112692
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce:
* Go on `res.partner` form view
* Add field `sale_order_ids` visible in the view
* Try to open one of the partner SO's by clicking on it
* Traceback, unable to read 'modifiers' on undefined
Unexpectedly, the field `order_line` is not available in the Sale Order
`activeFields` on the client side when opening the SO form view that
way, which leads to a traceback when trying to know whether that field
is readonly.
This commit makes sure the field is in the SO `activeFields` before
checking whether it is readonly.
opw-3097134
closesodoo/odoo#109541
X-original-commit: b37a2cf45e1f5b1422cd19269cd2b85085d75558
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Followup of b9e80c1403de0341a0c133a254142e53ef8c2842
In the last commit, we make it so when the tour was working as expected, the partner had an email.
But the problem which lead to another partner sometimes chosen instead was still there. We now make
sure to select the correct partner. Additionally, we supress an useless step.
closesodoo/odoo#109459
X-original-commit: 9b31ee81095ccef100c98cb0751b6e96d81f691e
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Compare list price as base price or list price in comparison or comparison preview
task-2795129
closesodoo/odoo#87134
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
`sale` module uses custom field class to provide extra features. Particularly,
it makes product field clickable depending on SO status. However, this feature
doesn't work in Studio context. Specifically, parent record might be not
`Record` instance for `sale.order`, but `StaticList` instance for
`sale.order.line`, which doesn't have `isReadonly` method.
Fix it by that `isReadonly` is not `undefined`. We don't need to make product
field clickable in Studio anyway.
opw-3098768
opw-3099942
closesodoo/odoo#107902
X-original-commit: 06e7ccd2fab28b46eeec28029e51ae7312e66d71
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Users were not able to access the product (product/template) form view
when the product was readonly (cf product_updatable field logic).
This commit makes sure that a user can always access the product form
view through either the external button or clicking on the product
field itself (when readonly).
Task-3063622
closesodoo/odoo#107237
X-original-commit: 7bf45b022e73a83d9b04350b8899919714e59223
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Valentin Vallaeys <vava@odoo.com>
There was a typo in the color_field xml not allowing to disable the
pop-up in case of readonly. A test validates the feature is active.
The color_field now displays the transparent symbol (instead of black
color) in case the color is undefined.
The product configurator also displays the transparent symbol for
undefined non-custom colors.
task-3013110
closesodoo/odoo#106669
X-original-commit: c67c32c2dbe10b4885ec1177852839b3d18ecf05
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Tour failed due to the always edit feature
task-3012774
closesodoo/odoo#103103
X-original-commit: 20032c71fbeb44c1b8f0e00ac93c7804c1ec602d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some onboarding tours were conflicting between themselves, with some
common steps. This commit introduces the possibility to skip a step
depending on the current DOM, making dynamic tours and ensuring tours
compatibility
task-3002442
X-original-commit: 1e4fb74f2cb8d500effa54d548dc9c29f12b32c1
Part-of: odoo/odoo#103036
class o_edit_product_configuration was removed during owl conversion and
its css logic is not needed anymore.
X-original-commit: 9b40bb011ae5430b8a082bc6ddd24ca9ec8fdcf1
Part-of: odoo/odoo#102245
The changes introduced by [commit 1] broke the getSelectedVariantValues method
when using the optional products modal with a preconfigured variant. When the
variant is preconfigured, the variant selection form is not rendered. As a
consequence the VariantMixin fails to retrieve the combination used when
calling getSelectedVariantValues.
In v14 this problem was solved by including an element in the DOM containing
the attribute value ids in one of its data attributes. Restoring this element
and the associated logic for retrieving it solves the problem.
[commit 1]: https://github.com/odoo/odoo/commit/2b832269f474d9b08c7c6cd827e5f78ebcfafeca
opw-2722176
closesodoo/odoo#101843
X-original-commit: 2959641fcee0c599162ed6b1dfc8efebd0c9211c
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Improve checkbox/radio design and the overall consistency, removing
'website_sales' overrides and defining `:hover` behaviors globally.
The odoo 'css_attribute_color' field has been adapted too in order to
match user's fields customization.
task-2907955
Part-of: odoo/odoo#98558
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
We now display only the lines that have documents linked to them.
In case, we want to display a line even if there are no doc, we
can do so by updating the list of counter to keep with
"getCountersToKeep()".
In case, there are no lines, we display a small message.
For now we always display the quotations, sale orders and invoices.
task-2947778
closesodoo/odoo#99373
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: sale, sale_product_matrix, test_sale_product_configurators,
website_sale_product_configurator
Previously, the product configurator used a transient model and a
corresponding wizard to configure products. In subsequent refactorings,
the product configurator was merged with the optional product modal, and
because this feature also needs to work in the eCommerce, all the
features are available in the modal which doesn't directly depend on the
form view.
Since the modal is capable of doing everything on its own, the form view
and its corresponding transient model are no longer necessary, the m2o
widget can just open the modal directly instead. The only thing that was
missing from the modal was the ability to selectively display the
optional products depending on the configurator mode (we don't want to
show optional products when we're configuring an existing product).
This commit refactors the product_configurator_widget so that it can
open the product_configurator_modal directly without the need for an
intermediate form view, and removes said form view and the corresponding
transient model.
Tours and tests have been adapted to have their selectors always match
the modal.
closesodoo/odoo#99219
Related: odoo/upgrade#3844
Related: odoo/enterprise#30860
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the popup for payment wasn't open after signature.
This is because Bootstrap no longer uses jQuery and jQuery .trigger
only calls jQuery handlers.
See 'o_sale_portal_paynow' button with data-bs attributes on it.
closesodoo/odoo#98290
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This PR is part of the whole migration of the sale javascript
code and related code to the owl framework.
Why: better developmet framework for javascript code in odoo.
This PR in particular targets the progressbar of sales team
appearing on the CRM app.
Task - 2918635
closesodoo/odoo#95565
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
Fix some uncommon nightly error on the runbot where a race condition
happened when the tour finished too soon. The test is successful but
during the browser cleanup, things are still happening.
task-2832564
closesodoo/odoo#91920
Related: odoo/enterprise#27600
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Arthur Detroux (ard)