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>
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
In the sale_signature tour, there was a step for entering auto mode when
signing for a payment. Since now the auto mode is selected by default,
it's not necessary to set it anymore.
task-2862209
closesodoo/odoo#92340
Related: odoo/enterprise#27793
Signed-off-by: Arnaud Joset <arj@odoo.com>
The kanban view for sales team is defined with a progressbar widget to
indicate sales target. There was a .include of KanbanRecord to customize
the behavior of that widget whenever the target value was not set. This
was problematic for the following reasons:
1. it is a .include, so it is applied to all kanban records in odoo
2. it is a lot of code,
3. and it mostly duplicate the editing logic in the progressbar widget
With this commit, the .include is removed, and a new
'sales_team_progressbar' widget is introduced to mimic the previous
customization. This should be safer and easier to maintain.
closesodoo/odoo#92071
Related: odoo/enterprise#27747
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since (at least) Chrome 94+, some element's sizing computation returns a
slightly different value (in the order of a fraction of a pixel). Sadly,
due to rounding, this difference has an impact on exact sizing
assertion.
Specifically in these drag-and-drop tests, it prevents the sorting from
being triggered as the "mouse" doesn't pass beyond the center of the
destination element (aka. next row).
By setting the position to `bottom`, this commit mitigates this issue by
making sure to pass that boundary, just like a real-user would do.
closesodoo/odoo#92292
X-original-commit: ed798b216063caa299800a56c617277aabdfb8fd
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
*sale_product_configurator
Since commit 50bf830, a crash occurred when a row containing a
many2one displayed with widget 'product_configurator' was dragged
and dropped.
For instance, open a quotation with at least two rows, and drag and
drop one of them.
Issue reported on task 2206228
closesodoo/odoo#48128
X-original-commit: d9c35b40b7df588f9e81142a2b272d9c7da06e04
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
Purpose
=======
- Moved the product_configurator into its own module now that we have a specific option for it.
The option only enables the p. configurator in the SO form.
The e-commerce should always allow customer to configure their products, even if the option is not checked.
This allows moving some of the code specific to the p. configurator into its own module.
However, a lot of the code has to remain in "sale" module since the e-commerce does not require the option
checked and needs the "configure product" feature in the shop by default.
(This is why the fields "product_custom_attribute_value_ids" and "product_no_variant_attribute_value_ids"
are still in the "sale" module)
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
Have a sales team without a target in the kanban view
click on define a target
Before this commit, the veiw wasn't rerendered, so the change apparently did not happen
(while the write was triggered)
Also, the Enter key did not work to validate the input
After this commit, the view is refreshed and the enter key works
OPW 1906938
closesodoo/odoo#29055
Targets commit d3530eb07e
Purpose
=======
[Follow up JCR testing]
Various bug fixes including:
- optional products dont show when they have variants configured on them
- when no variant is created, you cant choose the product one first time in the ecommerce
- when in debug, attribute and attribute value menu is double
- fix design of default picture in cart summary / product comparison
- fix missing href tag on product comparison "add to cart" buttons
- products with the "Can be sold" box unchecked should not appear in the product configurator
Purpose
=======
Product attrivutes can now have custom values.
These values are specified by the user during the SO creation.
They are also available on the webshop frontend.
Specification
=============
add a new mode to generate variants as they are added to the order/cart
- ability to define attribute extra prices & exclude combinations
Task #1871557
Purpose
=======
- Configure a product from a sales order as easily as in the ecommerce
The backend uses the same template as the frontend to configure a products and its options
- Display optionnal products of optionnal products in the "sale options" section
- Allow adding exlusions to some combinations of the product and/or
to some combinations of the optionnal and accessory products
Specification
=============
PHASE I
1. Improve the "Add to cart" with optional products
- When you add an option to cart, move the product to the cart & show the options of this option
- Don't open the option wizard if no option available (in case this module becomes generic,
it's better to skip this step when it's not needed)
- Display the options right under their related product in the cart
2. Do not allow to add the product as an optional product for itself
Why ?
- No functional sense
- Creates issues in the add to cart wizard
3. Exclude some attribute combinations within the product or with related options and accessory products
- Rename VARIANT PRICES button -> CONFIGURE VARIANTS
- When you click this button and select a value, open form view rather than inline edition
- Form view of variant values:
- Attribute
- Value
- HTML Color Index
- Attribute Price Extra
- Not Compatible with: o2m tab with 2 fields: Product AND Attribute Value (of this product)
[m2m tag selection]
- in any new line, autocomplete the current product by default
- Tooltip: A list of product and attribute values that you want to exclude for
this product's attribue value. Also applies on optionnal and accessory products.
4. New option to configure a product in a sales order line
- This option is only visible if the corresponding option is activated in the sales settings
- It opens a wizard to select a product template, configure related attribute values
and select optional products (based on frontend view)
- Attributes not compatible with other selected attributes should not be selectable
- Must work like in the frontend
