*: account,event_sale,fleet,hr_attendance,hr_contract,hr_timesheet,
im_livechat,point_of_sale,project
When the user tries to delete a record(s) from the reporting views, this
traceback will be generated.
Steps to produce (Example only):
- Settings > Technical > Actions > Window Actions
- Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode
in that action.
- Payroll > Reporting > Work Entries Analysis menu and select the tree view.
- Select one or more records and try to delete these records.
Error: A traceback appears: "cannot delete from view "hr_work_entry_report"
Handled the unlink access by using their model access of the reporting models.
similarly, this issue resolves in other reporting models.
Sentry-3975590063
closesodoo/odoo#125697
X-original-commit: 209d8c76ce9bb1d6cc7084d55b5623e939af8fbc
Related: odoo/enterprise#42825
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
This PR makes the following changes :
- In the demo data, add a fleet manager to the vehicle linked to Marc Demo & add a domain to that field to only list users from the selected company(ies)
- On the Launch Plan window change the dropdownlist for a radiobutton widget
- Remove the quick create and quick edit option on the launch plan screen
- Add a due date on the launch plan screen, the activities will be created on launch plan and the due date will be the one selected in the field
- On the activity type, hide the Schedule field if no value are defined on the previous field (suggest/trigger)
task-3337922
closesodoo/odoo#122298
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
=======
When you start a new trial of an app without demo data, you
want to have everything perfect and ready for your own configuration
closesodoo/odoo#122308
Taskid: 3328654
Related: odoo/enterprise#41423
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Install fleet
- Switch to mobile view
- Create new vehicle
- Click on model field > Select a model
Issue:
Clicking on a car model does not perform any action.
Solution:
Add class `oe_kanban_global_click` to kanban items in order to capture user clicks.
opw-3188104
closesodoo/odoo#122567
X-original-commit: 7b56586f256461d19a4c8999d7dab05a6e33b1e2
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
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>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
The introduction of Milk has brought new app icons.
Using the svg format creates a lack of anti-aliasing on the edges of the
shapes, which makes the icons look bad.
Since the png size has been reduced, we can afford to use the png format
to have the best possible quality without having a lack of performance.
task-3326633
Part of task-3326263
X-original-commit: e07cb722f2b11407a3ad093bd688b7d37afd5a88
Part-of: odoo/odoo#121886
*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The default `group_operator` of `Many2oneReference` is 'sum' (inherited
from the parent class `Integer`), it doesn't make any functional sense
to sum ids.
Also set group_operator to None on `co2` instead of override read_group
for the same result.
Part-of: odoo/odoo#110737
This PR :
- Adds 2 new default contract types to the data : Omnium and Leasing
- Lets the user search models by manufacturer name and model name
task - 3249291
closesodoo/odoo#117059
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit adds the loading="lazy" attribute to every img tags compiled
by the kanban compiler and modifies some kanban archs in order to use
img tags instead of divs with background-image style to load images
(this allows again the loading="lazy" attribute to work).
The purpose is to avoid loading images that are outside the user viewport
at all time in order to reduce the load on the network when new images are
loaded.
Steps to test: find all views that are using the o_kanban_image or o_kanban_image_fill_left
class and ensure all the images in these views appear in the network tab of devtools
when they enter the user viewport. Example: res.partners, hr.employee, ...
task-3102207
closesodoo/odoo#117049
Related: odoo/enterprise#39560
Signed-off-by: Géry Debongnie <ged@odoo.com>
before this commit, in the list view of
fleet (fleet.vehicle),
services (fleet.vehicle.log.services) and
odometer(fleet.vehicle.odometer) the vehicle_id
and model_id field with many2one_avatar is
not showing the image of vehicle and model.
* open fleet -> fleet -> fleet
* switch to list view
* model field will be with empty image
* similarly in services and odometer menus
after this commit, the widget will be removed
from the field as the avatar field doesn't
exists in the model level.
closesodoo/odoo#117752
X-original-commit: e57b6f898775a0e432ae1a21266a0f4bf82c0242
Signed-off-by: Kevin Baptiste <kba@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 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, form view for the model fleet.vehicle.cost.report model was not defined, thus on opening the form view of this model shows odoo generated form view.
after this commit, as the form view is added for the model, on opening the form, clean form will be displayed.
also in the file, there is a record with wrongly aligned corrected that and set create="0" attribute in tree to hide the new/create button.
closesodoo/odoo#110450
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, when the vehicle is assigned, it is checked from the first contract date, now it
will be checked from the order date
In this Commit, We added order date field in fleet vehicle
task-3054981
closesodoo/odoo#107073
Signed-off-by: Kevin Baptiste <kba@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@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>
This commit adds tracking to the "plan to change car" field in res.partner.
task-3086287
closesodoo/odoo#106845
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
Onchange methods are executed in "edit-mode", so you need to save to get the definitive
values saved on the DB, but if you do a write on it, that changes are immediately saved
to the DB, so if you discard the changes on UI, you will have inconsistent data. That's
why you have to do update instead, that only modifies the temporary dataset.
Courtesy of https://github.com/OCA/pylint-odoo/issues/356closesodoo/odoo#104539
Taskid: 3046426
X-original-commit: 5f18f068e62ba6cf6296c5f818b2cdfabed1fdfb
Related: odoo/enterprise#33409
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit will make date(time) raw_value an ISO string
instead of a native JS Date.
- Before this commit
In kanban templates:
- the raw_value property of a record's date/datetime field is
a native JS Date object.
The problem with raw_value is that JS Dates toString
method depends on the system locale and timezone.
In the code base, the usage of raw_value for date/datetime fields
usually parse the raw_value into a luxon DateTime object
in order generally to display it in a specific format, or in order
to compare it to another luxon DateTime object (e.g. the now instant).
- After this commit
The raw_value property of a record's date/datetime field
has become an ISO8601 string, instead of native JSDate toString
format (which I recall depends on system's locale and timezone).
The ISO8601 format is easier to work with.
Part-of: odoo/odoo#98980
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
Just doing the summer file cleaning. Move mail data into files named based on
their model, easing maintenance and searching for those data.
Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#98661
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>
When a record is created through xml data, its HTML fields should
receive a `type="html"` attribute, not a `type="xml"` attribute.
When important XML data with XML type instead of HTML type will have 2
differences:
- The field value will be prefixed by `<?xml version="1.0"/>`
- If the HTML contains multiple root nodes, the value will be wrapped in
a `<data/>` tag.
See `_fix_multiple_roots()` and the `xml_import` class for more details.
closesodoo/odoo#98239
Related: odoo/enterprise#30491
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
Avoid having too many search for, lead the end user to use the main one.
closesodoo/odoo#98096
Taskid: 2937036
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
prye-odoo