Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
This issue only occurs on Firefox because ´has´ is not supported
and the following rule is not applied:
https://github.com/odoo/odoo/commit/2cd0106e63785dd34553c2b4747d72b93b9a7afd
Anyway, there is an existing css rule that is applied if the field
class is correclty added.
Steps to reproduce:
- Open Sale
- Add some content in the sale order line
opw-3201461
opw-3285854
opw-3266130
opw-3244581
closesodoo/odoo#121979
X-original-commit: add1df806157c074fd1a3224d1d8bdf1922481fb
Signed-off-by: Pierre Paridans (app) <app@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 commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@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>
This commit moves the element inside the table to avoid that the
dropdown may overlap thead column labels.
Part of the overall v16 SCSS optimization/restyle, task-2704984
task-2946835
Part-of: odoo/odoo#98234
Before this commit, when two week calendar were used, the tooltip was wrongfully assuming which week were odd and even.
Even with correct information, it was not easy to fill and could easily lead to wrong information on the payroll.
closesodoo/odoo#56055
Taskid: 2308804
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
In Belgium, we need to support some partial time on 2 weeks.
For instance, a mid time, means you could work on monday, tuesday
and wednesday on week1 and monday and tuesday on week 2. Others payroll
softwares manage this.
Specification
=============
Add a checkbox on resource calendar to manage 2 weeks. --> Consider even/odd weeks.
Add sections on calendars (Like sales orders)
Modify methods in resources to apply this behavor generically.
Check that attendances aren't overlapped
Write an integration test for holidays - benefits - payslip
to check all this, + "credit temps" and wage modification.
Note
====
For the sake of simplicity, we only manage calendars over 2 weeks
to consider the odd/even weeks and keep an easy implementation.
For more complicated calendars (eg: over a months with specific targetted days),
it's better to create specific allocation requests and apply specific leaves
for those days, as it would be the case for parental leaves.
closesodoo/odoo#31674
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Jorge Pinna Puissant