After the bootstrap migration, the enterprise badge in the settings view
were the wrong color because the class bg-primary was not adapted. This
commit fixes that.
After the wowl views merge, the badge has become hidden behind the
navbar, because it can no longer modify the DOM of its label as it is
managed by owl. When there is no label, the widget appends the badge to
its own $el, and uses position: absolute to position it. This didn't
work because the closest parent that was positioned was the view itself.
This commit fixes that by giving a position: relative to the settings
box.
closesodoo/odoo#96580
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The css rules for the settings view should be in the corresponding css
file, not with the generic form view rules. This commit moves these
rules to the proper files and unnests some rules when the selectors are
specific enough, which generates less CSS.
Part-of: odoo/odoo#96580
Windows uses /r/n as newlines and the split parameter was not taking
that into account, thus inserting the /r character.
task-2742071
closesodoo/odoo#96422
X-original-commit: 90e565f811523968c297f0254f4aa7046c4e710e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit solves 2 problems in the list view:
- incorrect label for a column
- the label in the optional column dropdown can be different than
the label of the displayed column
When converting the list view, we used the displayName of the widget
and not its label.
In order to improve the consistency between the labels in the optional
column dropdown and the associated columns, we decided to use the same
label.
closesodoo/odoo#96408
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the subtypes are not correctly ordered when
none of the subtypes have a parent model. while it should be
order by parent model, then by sequence.
So in this commit, we will first check if both their parent model
are falsy then we can't order them (A = B). Then we will consider
their sequence, and they will be useful to determine the proper order.
task-2904015
closesodoo/odoo#96402
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit when multiple instances of the same product
were selected in a PoS session, `can_be_merged_with` checked if they
had the same price before merging them in a single order line. However
the order line prices were not rounded. In the case of a floating
point error in order line price calculation, this behavior resulted
in multiple order lines for the same product.
Steps to reproduce the issue:
1. Create a product
2. In the pricelist, create a formula of -10% discount based on cost,
and set the cost as 136.35 $
3. Open a POS session, add the product multiple times
4. The products are not combined in one group, each creates their
own order line
To fix this issue, we need to round the order line prices in this
function.
opw-2854304
closesodoo/odoo#96410
X-original-commit: 254521d302b31acd5b6f6cfbf49c184035b30eb0
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit fixes the profiler datetime usage by properly using the
'real_datetime_now' as a callable.
This was breaking the output json file when profiling.
closesodoo/odoo#96456
X-original-commit: 5fec27e42b033f79933afb3d0c85b142360981f9
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit introduces some information/instructions regarding the access
to the project/tasks depending on what the user has selected for the project visibility.
This should reduce confusion and thus increase productivity on the user side by
making the task of granting access rights more straightforward to the user.
closesodoo/odoo#95947
Task: 2917471
Related: odoo/enterprise#29455
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce the bug:
- Enable 'Multi-Step Routes' option in Inventory settings
- Edit warehouse and update Manufacture = 'Pick components, manufacture and then store products (3 steps)'
- Create a storable product 'P1' with BOM:
- BOM type: Manufacture this product
- operations: “OP1”
- Components: product 'C1' consumed in the operation 'OP1'
- Set Reordering rules for product 'P1'
- Run Scheduler and MO will be generated with order points
- Edit MO and add Producing Quantity less than to produce
- Validate the MO and create backorder.
Current behaviour:
- child/parent MO were getting visible when backorder was created in 2/3 Step Production.
Expected behaviour:
- No child/parent MO visible until child/parent relations are there
closesodoo/odoo#96533
Task: 2846768
X-original-commit: 14431b2497dcf4aaf778ef1b06e023101b00a4e2
Signed-off-by: Tiffany Chang <tic@odoo.com>
To reproduce
============
on settings -> document layout -> choose Bold with blank background.
print a document (quotation for example) that has at least 2 pages.
the second page of the document has a background.
Purpose
=======
the issue is caused by the condition :
https://github.com/odoo/odoo/blob/0436709f33e57479bd6d62c2e0a2de74743cbaa4/addons/web/views/report_templates.xml#L403
where we don't take into account the case where no background is set.
Specification
=============
to solve the issue the condition was corrected
opw-2888650
closesodoo/odoo#96528
X-original-commit: bf2ce0aa0c7d45c90d7ff104d5af5f99b29d59ae
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit, the "Edit Menu" was displayed for the restricted
editors, even if they didn't have the right to access the website pages.
This was leading to a warning in the "click_all" test with the demo
user, and didn't make sense for the real user (who was prompted an
"access denied" modal).
Now, this menu is displayed only for the website designers.
Additionally to that, the website root instance would load the wysiwyg
assets if it is created inside an iframe which has the "load-wysiwyg"
data-attribute. But the test was not correctly written (as
data-load-wysiwyg was the string 'false'). This would lead to a warning
in the console when a user with no website rights was accessing the
website client action, introduced in [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#96520
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475closesodoo/odoo#78221
Related: odoo/enterprise#23069
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Before this commit, the evaluation of the context was done for all
the context, even when only a subset of the context was needed.
Now, we evaluate only the attributes of the context that are used.
Part-of: odoo/odoo#78221
The `toPyDict` method is used to transform an object into a "python" dictionary,
by returning an equivalent object with the PY_DICT object in the prototype chain.
In practice, it is called everytime we create an evaluation context.
This is a performance problem, since creating the context is not cheap in the
case of Odoo form views: we need to iterate on all the values of the current
record, checking for each changes, applying all relational operations, ...
And even worse, almost all of the domains that we need to evaluate have very
simple conditions, which just needs to check the value of one field. So, it is
useful to make the computation of the eval context keys lazy, and this commit
make sure that pyjs does not undo the lazyness of the eval context, if any.
Part-of: odoo/odoo#78221
The view mode in which to display a legacy x2many field in a new form
view was badly processed. This lead those fields to be not renderered at
all (no list or kanban renderer displayed) or be renderered with the
wrong renderer in mobile mode. We fix that.
Part-of: odoo/odoo#78221
Sometimes a field component might need to know some other fields values
to render itself or for other purposes. In legacy, a mechanism allowing
to load some field values not displayed was available: a field would
declare a fieldDependencies object specifying some field names and
their types and the related values would be loaded along the other data.
Here we introduce the same mechanism for the new views.
Note that in a new view list, the tag widget is not currently supported
so that we have remove some lines in the list arch parser that were
useless.
Part-of: odoo/odoo#78221
Before this commit, if an arch contained a tree which itself contained
a tree, the parser would crash.
The reason for this crash is that the parser was trying to parse the
second tree with the model of the first. So it didn't know the fields.
The solution is to stop the exploration of children when it is not
necessary. For example, for fields, it is not necessary to explore
the children, it is parseFieldNode that takes care of it.
Part-of: odoo/odoo#78221
This rev allows the function built by the useViewButtons hook to take
a beforeExecute callback at call time, in addition to the existing
beforeExecuteAction callback that we can pass to the hook, at the
function's build time.
The rationale for this is to allow any caller to prevent the execution
of the action represented by the clickParams at the call level. It is
useful to check if a user is allowed business-wise to execute an action.
Part-of: odoo/odoo#78221
Previously, the statusbar field didn't display the currently selected
value for selection field in mobile, as the getter to compute the name
of the currently selected item only accounted for the many2one case but
not for the selection field case.
This commit adds handling for the selection field case and a test for
it.
Part-of: odoo/odoo#78221
Previously, legacy many2one fields and their extensions in new views
were unable to quick create records, this is because the compatibility
layer between the legacy fields and the relational/basic_relational
model is incomplete. This commit adds code to handle this specific case
Part-of: odoo/odoo#78221
The goal of this commit is to allow an X2m in list mode with a custom
controller to use the controller context when creating a new line with
a 'tab' keydown.
Part-of: odoo/odoo#78221
This commit adds the ability to set a class on a list view.
This class will be added at the same level as "o_list_renderer".
For example:
<tree class="myClass">
...
</tree>
Part-of: odoo/odoo#78221
This commit defines a "displayOptionalFields" getter that can be
overriden to force the presence of the optional column dropdown.
For instance, this is necessary in enterprise to add an item to
promote Studio.
Part-of: odoo/odoo#78221
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@odoo.com>
This commit converts the following fields to owl:
- account_resequence_widget
- grouped_view_widget
- account-tax-totals-field
Part-of: odoo/odoo#78221
Co-authored-by: luvi <luvi@odoo.com>
Before this commit, legacy fields spawned in wowl views didn't
receive the correct "mode" and "hasReadonlyModifier" params. They
do now.
We do not add qunit tests for this, as tours already identified the
issues, and it only concerns legacy fields that we'll soon remove
anyway.
Part-of: odoo/odoo#78221
Have an editable list view with a legacy many2one field (for instance,
an extension that hasn't been converted to wowl yet). Before this
commit, the edited row was unselected when the user clicked in the
many2one dropdown to select a value. The reason is that legacy
many2ones use jQuery autocomplete, that puts the dropdown directly in
the body, which is obviously not inside the table.
We do not add a qunit test for this, as it only concerns legacy
fields that are about to be removed, and it is tested in tours
anyway.
Part-of: odoo/odoo#78221
Before this commit, when there were more than one action menu (in
a list or form view), e.g. "Print" and "Actions", they weren't
displayed in the same line.
Part-of: odoo/odoo#78221
Previously, if a label for a field had an invisible attr which should
cause it to be invisible, and it was not at the top-level of a group, it
would be rendered even when it shouldn't. This was caused by the fact
that when we compile the form arch, we don't copy the t-if attribute
from the original label when generating the FormLabel component.
This happens to work when the label is at the top level of a group,
because when compiling a group, if anything at the top-level of a group
has a t-if, we move it from the node itself to the t-set-slot that gets
generated for the FormGroup component before we would generate the
FormLabel.
Part-of: odoo/odoo#78221
The form view is styled differently on small screens, and those rules
are based on the presence of the "o_xxs_form_view" className. This
commit correctly toggles it.
Part-of: odoo/odoo#78221
Before this commit, the More dropdown button of the ButtonBox
(which displays stat buttons) was broken i.e. the more button
was on another line because its size was wrongly set.
After this commit, the style is corrected, every button of the Box
is on the same line.
Part-of: odoo/odoo#78221
Before this commit, when the status bar did not have buttons to display
it was not displayed at all.
After this commit, we display it even if there are not any button inside.
Part-of: odoo/odoo#78221
Before this commit, the header declared in a form's arch was not injected
at the right place.
After this commit, the header's elements are put as children of the sheet_bg element
if present.
Part-of: odoo/odoo#78221
Before this commit, adding a component in the main component registry
after the initial mount did not work that is, the MainComponentContainer
never rendered the new component.
After this commit, adding a component to the registry works as expected.
Part-of: odoo/odoo#78221
It might happen that one wants to spawn a FormViewDialog with a
view that has a js_class, and the corresponding js code hasn't
been converted to owl yet (it is still an extension of the legacy
FormView). Before this commit, when that happened, the control
panel buttons of the form view weren't moved to the footer of the
dialog, because this isn't supported with legacy views. This
commit is a workaround, as it fallbacks on the legacy FormViewDialog
in this situation.
Without this commit, the main flow tour fails.
Part-of: odoo/odoo#78221
Before that commit a zero value for a monetary field would be wrongly
considered invalid. This would block many flows (e.g. a save).
Part-of: odoo/odoo#78221
Before this commit, the ace editor crashed when switching to edit mode or
when clicking in it.
After this commit, it works as expected.
Part-of: odoo/odoo#78221
Purpose
=======
Base the number_of_hours_display on the company calendar instead of the
employee calendar to avoid modifying the informative allocated value
in case of a working schedule change.
closesodoo/odoo#96419
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
For them, we are going to add the corresponding type of document, as was done in the credit notes
This is a fw-port, but it had to be done in community instead of enterprise
https://github.com/odoo/enterprise/pull/27180/commitsclosesodoo/odoo#96111
X-original-commit: 7a5e9b280ad10f52f5412505aa7fb250011a12ef
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- set a pricelist: discount, global, 10%
- set promotion program: free product
- In pos, select the product
Issue:
The product is deducted at its lst_price and not at the discounted price such as in `Sales`.
opw-2892748
closesodoo/odoo#96477
X-original-commit: ca933667e2b5e1633f08555b2852dcf30a4a11ab
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Samuel Degueldre