Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Adds back the direct link on the purchase line product's column when the
`product_matrix` is enabled. This allows the user to still click on the
product and go to its form when the module is enabled.
Also removes the direct link to the UoM, since it has no use.
Finally, sets a width for the product column in the purchase form to
keep it usable even when multiple columns are selected.
Part of task-3218314
Part-of: odoo/odoo#119381
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>
* 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>
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>
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>
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>
The product matrix was recently converted to OWL but the design was not
adapted to v16 style.
This commit revamps the table to better fits Odoo 16 design.
The previous table had issue with wrong color in dark mode and the
table head title were not aligned with the inputs.
task-3074063
closesodoo/odoo#107102
Related: odoo/enterprise#34743
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Product configurators were migrated to Owl, but some legacy code was
kept as not urgent to migrate (not required to drop the compatibility
layer of views).
This commit focus on the 'matrix' (or grid) configurator.
task-3056594
closesodoo/odoo#105841
Related: odoo/enterprise#34401
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Rationales:
- having a textual display "Unsaved changes" implied to the user that they
had to save
- having buttons "hiding" behind a hover effect on a span of text was
very unintuitive
- since we don't want an hover anymore, having text buttons would draw a
lot of attentions => use icons + tootltip instead
closes odoo/odoo#102757
Forward-port-of: #102605
Related: odoo/enterprise#32570
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
keep the +/- before the price, to correctly highlight the fact that it's
an additional price.
closesodoo/odoo#102245
X-original-commit: 32a2379b34b8646b681d3e42412bbc1ce2a045f1
Related: odoo/enterprise#32319
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
Instead of having to repeatedly manually call `onchange_quantity` at
different points in the code, it is better to have it be computed
instead.
- Logic is left unchanged,
- onchange calls from other methods are removed, and
- tests are adjusted to properly handle compute. I.e. remove
'date_planned': datetime.today().strftime(DEFAULT_SERVER_DATETIME_FORMAT)
from when PO lines are created since this sometimes resulted in
inconsistent date_planned values for PO line and the PO date_order
(by 1 sec), which could lead to inconsistently created 'date_deadline'
values for stock_moves' created by PO line qty changes. Issue
previously didn't exist because onchange was not always called.
Part of Task: 2695116 (to avoid adding more onchange calls for new
feature)
Part-of: odoo/odoo#87656
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>
Steps to reproduce the bug:
- install `”purchase_product_matrix”`
- Go to the purchase settings and enable “Warnings” option
- Create a product with variants
- Add purchase warning
- Create a PO and add the product
Problem:
The warning message is not appearing
Solution:
the `”_product_id_change()”` function has no return.
To trigger the warning message, we have to call the `”onchange_product_id_warning”` manually because it is not triggered automatically in the grid case
opw-2696007
closesodoo/odoo#80340
X-original-commit: 26bdebf6fd8b77013ea449a02184e8a843ffe9e9
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Same fixes for the purchase scope
1) Do not overwrite lines description if the line was not modified
2) Correctly recompute prices/sellers on quantity change.
When no new line was added to the PO through the matrix, the
prices/sellers were not recomputed, even if the qty was modified for
some products.
closesodoo/odoo#78971
X-original-commit: 591e424fd29856c1ce05ef3436db7f129fb29c2e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
What are the steps to reproduce your issue ?
1. Install 'purchase_product_matrix'
2. try to edit a PO with more than one line
3. try to change the order of a product line
What is currently happening ?
Traceback: TypeError: Cannot read property 'data' of undefined
What are you expecting to happen ?
Change order lines without traceback
Why is this happening ?
There is a function 'reset' that checkes if 'ev' exists:
https://github.com/odoo/odoo/blob/e0af10ccc92cb3b07f0eea6fa44ebf5a1bdc86aa/addons/sale/static/src/js/product_configurator_widget.js#L119
And in 'purchase_product_matrix' there is a override of this same function that calls it
and then tries to use an 'ev' attribute without checking it before
How to fix the bug ?
Check 'ev' before accessing it
opw-2513061
closesodoo/odoo#69856
X-original-commit: 25312bc576b9e0330eb316e77d8a177ee0434832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Open a purchase order with several lines
Switch to Edit mode
Use the movement arrow on the left of a line to move it upward/downward
At the end of the operation a traceback will popup
opw-2508480
closesodoo/odoo#69724
X-original-commit: 0d7c9db6d17e3268ae01a5b2d79b513c5b24a34f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
When adding a variant product, if the option "Variant Grid Entry" is
enabled, it will reset the delivery date of each purchase order line.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Variant Grid Entry"
2. Create an RfQ
3. Add the field "Delivery Date" to purchase order line view
4. Add a basic product (e.g. "[FURN_6666] Acoustic Bloc Screens")
- Keep its delivery date in mind
5. Add a variant product (e.g. "[E-COM12] Conference Chair (CONFIG)")
Error: The delivery date of the first purchase order line has changed
for no reason. Moreover, suppose that in step 4, the user defines a
specific date: the latter will still be changed after the variant
product is added.
When adding a product, the delivery date of the purchase order and its
lines are recomputed. However, an override of `onchange` ensures that
the new delivery date of the lines will be ignored if the `onchange`
concerns the field `order_line`. Here is the problem: when using the
Variant Grid Entry, the `onchange` concerns the field `grid`. As a
result, the new delivery dates are kept. This explains the creation of
`_must_delete_date_planned` in this fix.
However, when returing the result of an `onchange` linked to `grid`, the
result contains the existing lines (on client side) and the new ones
(from the Variant Grid Entry). If the field `date_planned` of the new
lines is deleted, the client will raise an error when it tries to render
these dates (it has no information about their value). Since existing
lines are of the form `(0, <client_id>, <values>)`, this fix only
deletes `date_planned` field for lines with <client_id> defined.
OPW-2454164
closesodoo/odoo#67972
X-original-commit: d2d495bca3e91862470702f1ef07aa27c33d8e2d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- Install purchase_product_matrix
- Go to Purchase and create a PO
- In PO Line, type a text (i.e. test) in product field and use quick create option
Description and UoM fields should be updated following product creation, but they are not.
"onchange_product_id" is not triggered.
"purchase_product_matrix" module overrides "purchase.order" form view by replacing product_id
field by product_template_id field.
"_onFieldChanged" function should execute "_onTemplateChange" when product_template_id is changed
and if id is set, which would trigger "field_changed" on product_id, but it cannot be done after
a quick create as id is false.
opw-2462538
closesodoo/odoo#67605
X-original-commit: 3c082b9a47be35579a454f13edc230ac3029922d
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Set up a DEMO product with
- warning message on sale
- variant
- Order Grid Entry as Sales Variant Selection
Create SO, configure this product
Warning message doesn't display
opw-2442352
closesodoo/odoo#64894
X-original-commit: 50ccbdb983fda289cb9fe740ae711d510386d878
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closesodoo/odoo#64683
X-original-commit: 69cadbe1be6320d96fe9bc5bf8dd808f87d735c0
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
- Install Sales and Sale Matrix
- Go to Sales > Configuration > Settings and activate "Variant Grid Entry"
- Go to Products and edit a product with variants (lets call it "Product A"):
* For "Sales Variant Selection" in "Variants tab", choose "Order Grid Entry"
- Go to Sales > Orders > Quotations and create a quotation
* Add any product without Variant Selection set to "Order Grid Entry"
* Add "Product A" with 1 attribute
* Add any product without Variant Selection set to "Order Grid Entry"
- Here there are 3 products in the quotation with "Product A" at the second position
- Save the quotation
After the save the position of "Product A" is moved to the last position.
In a new quotation, every new order line has a sequence set to 10, except for products
with Variant Selection set to "Order Grid Entry" that set the sequence to the previous one +1,
which will put it in the last position even if another product is added after it.
[All of the above steps and explanations can also be applied to Purchase]
opw-2303096
closesodoo/odoo#55342
X-original-commit: 17c1caec4fefd089586c62c40ac5a2232eed3dcc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Sales > Configuration > Settings
- Activate "Variant Grid Entry"
- Go to Products and edit a product with variants (lets call it "Product A")
- For "Sales Variant Selection" in "Variants tab", choose "Order Grid Entry"
- Go to Sales > Orders > Quotations and create a quotation
* Add any product except "Product A"
* Add another product except "Product A" and the previous one
* Switch the 2 added products with the sequence arrow widget.
It allows to be sure that the 2 added products have 2 different sequences.
* Add "Product A" with 1 attribute
- Here there are 3 products in the quotation with "Product A" at the third position
- Save the quotation
After the save the position of "Product A" is not the same anymore.
The bug comes from the fact that when using the matrix configurator, no sequence is provided
and the product is added with the default sequence of the SO line which is 10.
The issue is fixed by checking the sequence of the previous SO line if there is one.
[All of the above steps and explanations can also be applied to Purchase]
opw-2221991
closesodoo/odoo#51112
X-original-commit: 1a2d7e3fa0f33d90c74d3fd5a5ef486b56d8f512
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit moves some step utils in a dedicated file and add new ones.
These steps will be very useful for the Main Flow Tour to avoid
duplicated code.
To do this, we also had to transform it into functions to allow
utils to call each other. Existing one are converted for
standardization purpose.
Note that 'WEBSITE_NEW_PAGE' wasn't considered as an util.
This is a very simple step only used twice.
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
as we cannot do the test in product_matrix, add the purchase equivalent
in purchase_product_matrix to also test the matrix in this case.
X-original-commit: 9d7024a5327939de3c145928782936000d26bd33
Martin Trigaux