| Age | Commit message (Collapse) | Author |
|---|
|
— In a SO, create a section or a note;
— Add an invisible modifier (with studio for example).
Before this commit, the table-cells of the section/note were not aligned
any more, and the delete button (trash-can icon) wasn't available.
In a list, the invisible modifier uses a display: table-cell to keep
table cells aligned. But in this specific case, the display is already
none, because they are hidden cells. Therefore, the invisible modifier
it removes the display: none in the hidden cells, this has as outcome
that the table cells are not aligned any more.
Now, the hidden cells cannot have an invisible modifier.
opw-2117714
closes odoo/odoo#40584
X-original-commit: d040f02dd0140d9b7128e806e4a974fe1e8aa0d3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
*:
- account
- barcodes
- calenndar
- hr_timesheet
- mail
- mass_mailing
- partner_autocomplete
- web
- website_slides
This commit removes description of fields that should not be shown in
non-debug mode Studio. Only field widgets whose own description is
set are displayed in non-debug mode Studio in "Widget" of sidebar.
In other words, even if any ancestor has a description but not the
current widget, it won't be displayed in the sidebar in non-debug
mode.
Task-Id 2056992
closes odoo/odoo#35902
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
Explicitely return the extension of the listview to allow to modify it
in other modules
closes odoo/odoo#34672
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
This commit adds a new parameter on fields for list view and one2many.
The parameter name is "optional" and its values are "hide" or "show".
Columns of the list view which have the optional parameter set are
listed in a dropdown that can be toggled from the last cell of the
table header. The ones with optional set to "hide" are hidden by
default.
User choice is stored in local storage. If no saved parameter can be
found in local storage then the default value from the view is used.
Due to the overflow behavior of the responsive table, we were forced
to wrap the table-responsive div in yet another div. We changed the
o_list_view class on the table to o_list_table in order to reuse
the more generic o_list_view class on the top-most div. CSS rules
and selectors had to be updated according to this change.
Task-1902765
|
|
A `description` key has been added on AbstractField and all generic
field widgets ; it is used to display a more user friendly name (both in
the webclient and in Studio).
Non-generic field widgets have an empty string as description.
Related task 1918327
closes odoo/odoo#30131
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
Before this rev., widgets were absolutely positioned in table
cells. This cause an undesired effect with text fields, as their
textarea overflowed and overlapped the next lines.
With this rev., wigdets are now statically positioned, and the cells
height and width don't change when switching a row to edit mode.
Part of task 1915702
|
|
Task #1891970
Original p. configurator commit d3530eb
Purpose
=======
- The p. configurator now comes with a widget that is "o2m" like in the SO lines view.
The widget is only used on the added "product_template_id" field on the SO line.
This widget controls the opening of the configuration window and removes the need of a "Configure a product" button.
The "SectionAndNoteListRenderer" is now cleaned from p. configurator specific code.
The widget is also responsible for handling the configuration provided by the p. configurator form
and applying it on the SO line with a 'field_changed' event that updates all the necessary fields.
- Added support for 'MULTI' and 'DELETE_ALL' operations on X2Many fields in basic_model.js
- 'MULTI' allows to batch multiple operations at once
- 'DELETE_ALL' behaves like 'DELETE' with all the current data of the field
Spec
=======
- remove "configure a product" from sale order lines
When the product configurator is active, replace the product_product_id by a product_template_id
in the sale order line. When we select a template without variants, it sets the variant automatically,
but when we select a product template having variants, it opens the configurator dialog.
- add a widget to modify the product configuration in the sale order line (next to product template field)
- UX improvements:
- Invert image and configuration in the main screen
- If the product doesn't have an image, hide it instead of showing the placeholder (only for first screen?)
- new independent option in sales settings to activate product configurator.
(same in e-commerce)
- demo data: Change demo data to set Customizable Desk & Conference Chair as make to order
- If only one attribute value that is Custom, don't display radio, selection or even color box
|
|
after the update of jquery, all promises are asynchronous.
In the invoices, a class was added to the section and note field before
it was rendered.
To fix this, we are now waiting for the rendering to be completed before
adding the class.
closes odoo/odoo#31666
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
not pricelist is defined
This bug had been introduced in https://github.com/odoo/odoo/commit/154fc7d9dd550d35b7266af024e54c20e18938fc .
|
|
Targets commit d3530eb07e24278117ab396ecb86a59deecc312d
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
|
|
Targets commit d3530eb07e24278117ab396ecb86a59deecc312d
Purpose
=======
[Follow up AL review]
Removed the default_get override in the sale_order_line model.
- The default values to create records are now specified by pefixing them with "default_" in the JS.
That will use the built-in framework method, which is more simple/clean.
- The "list_editable_renderer.js" file for the product configurator was removed and its content is now merged within
the SectionAndNoteListRenderer.
Updated fields:
- [sale_order_line in sale/sale.py] "product_no_variant_attribute_values" to "product_no_variant_attribute_value_ids"
|
|
The widget was made of duplicate code that was impossible to maintain.
Now we instantiate the correct widget directly.
PR: #26566
Task: 1869469
|
|
Before this commit, a textarea would not resize when its value changed if the event was different than "input" or "focus".
This commit fixes it by also listening to the "change" event, and by triggering it at appropriate times.
PR: #26430
Task: 1869469
|
|
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
|
