*: hr_holidays, stock, sale, product, web, sale, purchase, stock,
website, survey
Adapt some custom control panels (mainly for custom reports) to the
milk controlpanel.
hr_holidays:
Move the buttons to create a new time off or a new allocation to the
"create button" slot and transform it into a dropdown (creating
allocation requests is clearly a secondary action, not a primary one)
stock:
3 lines does not fit, must be on 2 lines
Part-of: odoo/odoo#116641
While creating a new product in product category with barcode value in inventory
module, `_check_barcode_uniqueness` method is called. In which variable 'domain'
is passed, and getting wrong value.
Steps to Produce:-
1) Go to Inventory then configuration
2) Click on 'Product Categories' under products
3) Click/Create Product Category
4) Click stat button 'product'
5) Create a product
6) Then add barcode value
7) Click on Save
8) Trace-back will be generated
Reason:-
While creating new product from product category when user add the barcode value
in product form, the '_check_barcode_uniqueness' method is called. In this
method the value of 'domain' is getting updated by reference from variable
'domain' from method '_search' present in the same model.
This results in a traceback with the message
'Invalid field product.packaging.categ_id'.
Applying these changes will resolve this issue.
sentry - 4073963761
closesodoo/odoo#121072
X-original-commit: ce9889e314ae696773ce040f662569e281abe700
Signed-off-by: Nicolas Lempereur (nle) <nle@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
What are the steps to reproduce your issue?
- Create a product with more than one attribute.
- Let say color White, black and purple
- Create a 'draft' invoice for the purple product variant
- Remove the 'purple' attribute value from the product
- It will archive that variant (because the account.move linked to it)
- Try to delete the attribute value from menu Sales > Cofinfiguration > Attribute
What is the current behavior that you observe?
- technical error message
What would be your expected behavior in this case?
- non-technical message for end-users
Solution :
- Change both message to tell user he cannot delete the value if the value has been referenced somewhere else.
opw-2623583
missing forward-port of db1e52f0234f73e1bda22a411baba7b1f0994d5a
closesodoo/odoo#120495
X-original-commit: 0c8c43d50a574d73d9d5ac925eb16faf730a76ba
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Following 83c52575d0 we activated or created pricelists as soon as a
currency was activated/created/deleted, for every company that might already have another
pricelist setup done, which was quite confusing.
With this fix, we ensure this will only happen:
- at company creation
- when enabling the pricelist feature
- when enabling the multi-currency setting (only the first time, unless the pricelists were
disabled manually afterward)
closesodoo/odoo#120039
X-original-commit: 4c0146d939e40e9433794802388cf06147e716f2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
before this commit, when deleting a product
category from a db where expense category
is already deleted before this commit [1]
is raising exception
after this commit, exception wont be shown
in existing db where expense category is
deleted.
1 https://github.com/odoo/odoo/commit/09e4b2fb586ac83adb984672e027ce6dd62affb2closesodoo/odoo#119754
X-original-commit: 20b5518110b233ba3b59158a8362db04b9a89aad
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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>
When your pricelist item price is based on an other prcicelist in
another currency, the wrong currency is given to the function
_get_product_price. we sould give the currency of the base_pricelist
instead of the target one.
Here is a example:
We have a priclist in INR based on a pricelist in USD. And the company
currency is euro.
When we go for the first time in '_compute_base_price', where we'll call
_get_product_price to get the price from the base pricelist (the $ one)
We get as src_currency the USD and target the INR. Since we are calling
_get_product_price with INR as currency, when _get_product_price will
call _compute_base_price, we'll get EUR as src_currency and INR as
target.
This will lead to apply on the EU price (the one on the product) the
rate of EUR->INR then apply over it USD -> INR. Instead of EUR -> USD
and then USD -> INR
closesodoo/odoo#119505
X-original-commit: 8ace9942368688dc1183133f451ea788a03e0f14
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
The product configurator dialog was still in legacy code as it was not
required for the migration of the views to OWL. Now that we're moving
forward with the removal of other parts of the legacy code, this dialog
had to be converted as well.
Some parts of the logic have now been rewritten in OWL, getting a better
share of the logic between the server and the client.
The product configurator in e-commerce still uses the old implementation
and will be refactored in another task.
task-3056806
closesodoo/odoo#106511
Related: odoo/enterprise#39525
Related: odoo/upgrade#4550
Signed-off-by: Valentin Chevalier <vcr@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>
When printing the label of a lot, the datamatrix may overlap the
product/lot name and will overlap the 'best before' date.
To reproduce the issue:
1. In Settings:
- Barcode Nomenclature: GS1
- Enable "Print GS1 barcodes for lots [...]"
2. Create a product P:
- Name: a long name
- Type: Storable
- Barcode: 1111111111113
- Tracking: USN
- Expiration Date: True
- Dates > Expiration Date: 1 days
3. Process a receipt with 1 x P
- The serial number should be long
4. Print Labels
- To Print: Lot/SN Labels
- (Confirm)
- Format: 4 x 12
Error: the datamatrix overlaps the product name, the serial number,
and the 'best before' date
For the product/lot names, we can only improve the situation. If the
user define a too long name, the issue will still happen and nothing
can be done
For the dates, we can shorten the labels. That way, the dates will
always be correctly displayed
OPW-3193836
closesodoo/odoo#116541
X-original-commit: f175897cefd1db149e94a50882d9e7babfc6293d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@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#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@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>
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>
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
Steps to reproduce:
- Go to a product with a long name
- Inside the product page go to "print labels"
- Choose "Dymo" as label type and print.
(For barcode you need to add a barcode number to the product.)
Issue:
The product name is not displayed correctly on the label because
is too long.
Solution:
Removing the fixed height int he label seem to have good behavior with
sizing the text.
opw-3120807
closesodoo/odoo#114097
X-original-commit: 37b49c6ced839cd82b77819845a52ba2cf8c4ab8
Signed-off-by: Tiffany Chang <tic@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>
Step to reproduce issue:
- Go to sales settings, activate "Unit of Measure"
- Set user define default of field "uom_id" of model "product.template"
- install "loyalty" module.
While loading file "addons/loyalty/data/loyalty_data.xml" file it will create product and gives traceback.
Or
- It will also give error while upgrade database from 14.0 to 15.0 or more
Note : This error occurs while there is user-define value for uom_id is set and any module tries to
create product from data file.
Current behavior:
- When product creates, uom_id and uom_po_id gets default uom value from
"_get_default_uom_id" method which return "Unit" uom as default.
But when user have default value for uom_id(let's suppose Days), it sets that default
value and for uom_po_id we got uom value as "Unit".
- So now as uom category of Days and Unit are not same it violates "_check_uom" constraint.
Traceback: https://pad.odoo.com/p/utpr-set_default_uom
Soultion:
- When product creates, if there is default value for field uom_id in "ir.default" then
"_get_default_uom_id" method sets same value for uom_po_id.
closesodoo/odoo#113300
X-original-commit: 33a20cf799a6cbca6a55cb82f90c4451df60fa1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This method is not used by rpc calls and wrongly allowed users to read the standard_price
field by calling the method through rpc.
Make it private to reduce its uses and avoid this potential leak of information.
closesodoo/odoo#113234
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Clarify the uses and impacts of current_attributes_price_extra and
no_variant_attributes_price_extra context keys.
Group the key specification and usage.
Provide a clear API shared by templates and variants.
Part-of: odoo/odoo#113234
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
- Places the buttons added in `stock` before the "Print Labels" button,
that way, the "Update Quantity" button is always the first button;
- Adds some depends on compute's methods, so that way it displays the
"On Hand" and the "Forecasted" stat buttons, and the weight and volume
UOM even if the product is new and the record wasn't saved yet;
- Adds the "Update Quantity" button in the product's forecasted report
and removes useless attributes of the "Replenishment" button;
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>
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
It is currently not possible to write the barcode of an archived
product template. The inverse method does not consider case where
the variant of the template is archived
OPW-3109967
closesodoo/odoo#110697
X-original-commit: 968d0dff823f8e5d0871feaf8b09233fbb91b4de
Signed-off-by: Adrien Widart <awt@odoo.com>
Removes the constraint of using a pricelist and makes all sales flows
rely on the currency of the sale order (or repair order)
task-2735672
closesodoo/odoo#84920
Related: odoo/enterprise#24716
Related: odoo/upgrade#3642
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Since https://github.com/odoo/odoo/commit/3752b3166ec6bbb5c6ea55f96bb521381bf2b2d9,
the currency of the test architecture is not fixed anymore to USD (but is by default).
Therefore, the nightly runbot tests of the localization (l10n_* modules) all fail
when verifying the company currency is USD (because the localization sets the company
currency to the country one).
This commit adapts those checks to stop enforcing the USD currency as base,
only enforcing that the currency used is the company one.
closesodoo/odoo#109807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Damien Bouvy