This reverts commit 3b9401c354.
It shouldn't have been merged in the first place. The PR was `r-` but it
seems like the mergebot bugged and still merged it because there was an
occurence of `r+` in the sentence which asked robodoo to `r-`.
> robodoo r- just to be sure, since there was a random r+ not [...]
Rationale of the revert:
- Bad field name:
- "ecommerce" in product module
- "ecommerce" but used in POS
- Arguably very low value to share the field -> This field is used in
ecommerce to add info exactly between the price and the name of a
product. There is low chance that you want to share that exact
information with the POS.
- Technically, it couldn't work. What you design in website builder on
the product page is related to website assets JS and CSS, which are
not loaded neither in the backend and neither in the POS.
It was leading to multiple critical issues, mainly:
- Losing the whole style of the content (CSS)
- Breaking completly the snippets (visually and design wise) (CSS/JS)
- Not even show (JS is in charge of showing the content eg)
Note that the same issues were already existing in that field in the
backend (it's shown in the product form view). The ecommerce team was
looking for a solution to make it work, but it's impossible as to work,
it would need the website / frontend assets, which can't be loaded in
the backend / POS.
The cancel of this PR was validated with PO of POS and ecommerce
following those explanation, which they weren't aware of.
Apart from this revert, further PR will be done to:
1. Remove the field from the product form view (ecommerce app)
2. Create a new field for POS
Revert of https://github.com/odoo/odoo/pull/136906
task-3524272
closesodoo/odoo#137514
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds a popup to show product information when clicking on an
info button in the product card in the self order app. The popup shows
the ecommerce description and the name of the product.
The ecommerce description field has thus been moved from website_sale to
the product module so that the pos_self_order module can use it.
closesodoo/odoo#136906
Task-id: 3524272
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently the user cannot modify the order as he adds new attribute to the product.
In this commit he will be able to do that
task-3451377
closesodoo/odoo#131514
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently there is no efficient way to suggest extra-options to
customers in PoS or eCommerce. Extra options should be easily selected
by customers (or PoS waiters) with checkbox. Each checked option would
add an extra-price to the product price and appear on tickets,
receipts, invoices, kitchen display, ...
This commit introduces a new type of attribute: multi-checkbox. This
will not create product variants. A default extra-cost is defined at the
attribute level, but it can be changed at the product level.
The new attribute is available in Sales, not yet in eCommerce nor in PoS
(it will be in a future task).
task-3256585
closesodoo/odoo#130915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Introduce new model of "Product Documents" to hold documents linked
to a given product template/variant, displayed on:
* quotations
* confirmed sale orders
* e-commerce product page
This will also replace the previous "Digital Files" (website_sale_digital)
logic & module, which allowed to specify product documents available
to customers after the SO invoice was paid.
This exact feature will be lost after upgrade, since we only keep the
choice to link documents on quotations/orders, but:
1) on e-commerce, carts are supposed paid when confirmed
2) on portal, the "Online Payment" settings makes sure the users
have to pay to confirm their quotation.
therefore we consider new configuration sufficient, without needing
a "paid order" choice as well.
task-3249201
Part-of: odoo/odoo#132739
- Updates the product.product kanban view so that it matches
the product.template one.
- Fixes the favorite button
- hr_expense also requires the cost to be shown
task-3457035
closesodoo/odoo#131208
Signed-off-by: William André (wan) <wan@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
before this commit, vendor product name and
vendor product code was not added in
vendor pricelists search view
after this commit, vendor product name
and vendor product code is added
closesodoo/odoo#129301
Signed-off-by: William Henrotin (whe) <whe@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>
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>
When no product is linked to a given tag there is no need to display
a void many2many. Indeed tags are configured mainly from products and
this field is used as a reminder of its usage.
closesodoo/odoo#124342
X-original-commit: 42ab359785fb38c098a524d03535c3aa6cca1173
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
add chatter to product pricelist to improve collaboration. Track
currency, company, country groups, discount policy and website fields.
task-3316528
closesodoo/odoo#121244
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Following 459760c, the `barcode` field wouldn't appear on a new product
form until the form was saved at least once.
This was due to the new product not having any variants until it was
saved.
In the case of the product not having any variants, we check if it does
have a least one attribute at the same time (which would be the case for
dynamic attributes).
closesodoo/odoo#121925
X-original-commit: 5f3db6683ab191cb68af4c8d6bb2e86a5b114ee1
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce:
- Inventory -> Configuration -> [Products] Attributes
- Create new Attribute with 'Variants Creation Mode' set to
'Dynamically' with a few values
- Inventory -> Products -> Products -> New
- Set the new dynamic attribute to the product and save
- If you try to set a barcode, the field will empty itself at each save
When a product is created with 'Dynamic' attributes, the variants will
only be created once the combination of attributes is used. So initially
there is no variant, hence nowhere to set the barcode.
So we avoid letting the attribute being set when there is still no
variant.
Part of task-3218314
Part-of: odoo/odoo#119381
This commit follows the addition of the OWL date picker and intends to:
- update views calling daterange widgets to use the new syntax (and
remove the end date field from the view in most cases);
- change the remaining components extending the previous DatePicker and
DateTimePicker components.
Part of task 3121497
Part-of: odoo/odoo#112171
This commit adds two autoresize hooks for text inputs and textareas to
make it adapt their size (width for text inputs, height for textareas)
depending on their content.
The commit therefore solves the issue of several form view task titles
being restricted to 1 line while it can be annoying if the title is too
long. The autoresizeTextarea feature was moved from TextField to the
autoresizeTextarea hook and the autoresizeInput feature was moved from
the AutoresizeInput mail component to the autoresizeInput hook.
The TextField component has a new option for disabling linebreaks.
task-3138826
closesodoo/odoo#117355
Related: odoo/enterprise#39493
Signed-off-by: Géry Debongnie <ged@odoo.com>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- adding a label 'last update' to the stat button in project form view.
- indicate 'my project' in the tab instead of 'project sharing view in portal' in project sharing.
- set the first non-folded stage of the project as default on newly created tasks.
- remove user confirming the SO as the default project manager.
- hide fields service_tracking, service_upsell_threshold if sale_ok is false.
- set purchase_method to purchase by default if product is of service type.
- remove the : next to the totals labels and decrease the font-size for values of 'total hours'
and 'remaining hours' in timesheets notebook in project task form view.
task-2897867
closesodoo/odoo#96548
Related: odoo/enterprise#29774
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Manisha Tulsiyani <matu@odoo.com>
The main objective of this commit is to make checkboxes consistent
and fix their spacing issues.
Prior to these changes, the checkboxes on the `product_view` were
too close to their neighboring option labels, making it difficult to
know which checkbox to tick.
The new changes fixes inconsistencies in general such as undesired
hovering effects and the cursor behaviors on disabled inputs.
This commit also removes the margin in the checkbox template since the
padding from the checkbox wrapper compensates for the spacing between
the checkboxes and their respective labels.
Tweaking the selector in `settings_form_view.scss` to ignore boolean
field inputs allows us to get rid of max-width and margin overrides
introduced in commit b90059e936.
Most checkboxes were already falling under their labels on mobile, but
this change impacted those that were not. To address this issue, we
decided to consistently change the position of the checkboxes left to
their labels for small devices in form view.
This required slight adjustments to the `form_group.xml` template.
Still in form_view, for some of the specific checkboxes such as
`o_checkbox_optional_field` the changes in `form_controller.scss` are
made to mimic the new behavior for mobile sized screen.
However, if they are using the form_group template, their behavior
is unchanged at the moment.
Finally, even if these changes makes it better for most of them, some
checkboxes in `settings` still require some minor adjustments and will
be addressed in task-3113372.
task-3094083
closesodoo/odoo#114612
X-original-commit: ddb7574f97f11e69f0304c8bd8d55c2c53ab53fd
Related: odoo/enterprise#37887
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Makes the `product.packaging` `product_id` required in the model instead
of the view only, since a packaging is supposed to always be relative to
a product.
Edits some views to add the default product in the context and makes the
field readonly if there is no `product_id` (that way, the user can't
no more create packaging without product).
Also, removes the domain in the action to display the packaging list
view so the user can see if there are some packagings without product
and can eventually delete them.
task-3076044
Part-of: odoo/odoo#109511
Migration of the js code of `product_pricelist_report` to OWL.
Task - 3058360
closesodoo/odoo#105341
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Xavier (xlu-odoo) <xlu@odoo.com>
UI improvements for the form of product.product model.
task-3043184
closesodoo/odoo#111052
X-original-commit: d8bc64e6cf04291370e577abe8c58303ae4a9741
Signed-off-by: William Braeckman (wbr) <wbr@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>
In pricelist form view and product form view, pricelist rules are now invisible if referring to an archived product or an archived pricelist.
task-2920563
closesodoo/odoo#105112
Related: odoo/enterprise#33910
Related: odoo/upgrade#4028
Signed-off-by: Arnaud Joset <arj@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
The group `“base.group_user”` is added in the view for the field
`standard_price` while it is already set on the python side:
https://github.com/odoo/odoo/blob/16.0/addons/product/models/product_template.py#L76
this causes an issue in the case of a product with variants,
the invisible attrs is ignored, the `standard_price` and
`uom_name` field are hidden, but the label will still be displayed
opw-3076827
closesodoo/odoo#106925
X-original-commit: 206e88b0ad9fdb6e1767c93b3eca8feeecddd3da
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
Go to a product form view that has a BoM.
Issue:
The price is diplayed collapsed with the units and currency text.
Solution:
We need to remove the class "o_row" in order to be displayed in 2
columns as it is in other versions.
opw-3041120
closesodoo/odoo#104460
X-original-commit: 812614b7d6e194f510491ff83f9a8e48594ae7c5
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Within Purchase tab:
- Make Quantity hidden by default.
- Move Currency right after Price.
Move Purchase Description to the right of Vendor Bills.
closesodoo/odoo#102702
Task: 3004014
X-original-commit: b3e78b5a8f825650123004a8b8677aaacfe6b43e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
This commit adds the possibility to change the product tag color on a product and also to edit those tags from a submenu of the ecommerce.
task_id=2904805
closesodoo/odoo#100717
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
With the change to 'always edit' on form views by default, several
'oe_read_only' fields had to be modified to play nice with the fact
that in most cases, there is no read_only mode
closesodoo/odoo#101188
X-original-commit: 868992abeeda983768323e1126b5643eff8fdb33
Related: odoo/enterprise#31810
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit, when trying to create or edit a product from
add a line and open the 'Create Product' popup, the label 'Sales Price'
is not visible.
This issue happened due to this commit
https://github.com/odoo/odoo/commit/46526f629f7645eaac8ce86e81e806cfa392b8b8
Due to the above fix, in the product template, the label for the
list_price field becomes invisible. So here we replaced it with
a label of the lst_price field.
task-2983733
closesodoo/odoo#100197
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since the fields were rewritten in owl, they all have a width of 100% by
default, which is what we want when displaying a field on their own.
In some places, fields are used as part of a longer block of content (eg
unit of measure behind a number). In those cases, we want to display the
field inline, which requires the addition of the oe_inline class in the
arch.
There was also a missing piece of css for the monetary field, as the
previous rule no longer applied because of the slight changes to the DOM
structure.
closesodoo/odoo#99529
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Romain Derie