This PR prepares the ground for the one introducing the new env in discuss.
The signature of the notify function has changed a lot from the one in the old env.
In order to ease the transition and reduce the noise, the discuss models now
rely on the messaging's notify function.
task-2582313
closesodoo/odoo#89877
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: calendar, hr, im_livechat, mail, mail_bot, snailmail, website_slides.
This PR prepares the ground for the one introducing the new env in discuss.
The signature of the rpc function has changed a lot from the one in the old env.
In order to ease the transition and reduce the noise, the discuss models now
rely on the messaging's rpc function.
task-2582313
closesodoo/odoo#89858
Related: odoo/enterprise#26676
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
When creating a user and employee from the wizard, the employee was
taking the default name from the context instead of the one chosen
in the wizard.
closesodoo/odoo#88368
Taskid: 2819821
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
Departure reasons could be used on business code (eg: payroll).
Currently the mapping is made based on the xmlid, but it could
happen for some customers to create several departure reasons
of the same kind. (ex: "Resigned - Salary" or even
"Resigned - Personal Reasons").
This commit uses the departure reason on _get_default_departure_reasons
to allow considering them together.
closesodoo/odoo#87662
Taskid: 2811192
X-original-commit: c7f46a4760fa2beb7d50b4b95f10e14a1a326423
Related: odoo/enterprise#25771
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Having both an activity type "Request Signature" and "Signature
Request" on the plan were confusing and misleading for the users.
Related odoo/enterprise#25511
Related odoo/upgrade#3398closesodoo/odoo#87082
Taskid: 2796407
Signed-off-by: Kevin Baptiste <kba@odoo.com>
* Redesign views
* New layout for the job kanban card + redesigned menu
* Create new reports
* Candidate Sources: get a better view on where applicants are
coming from;
* Time in Stage: shows how long an applicant is in the current
stage.
* Archiving a job archives applicants as well
odoo/enterprise#24816odoo/upgrade#3395closesodoo/odoo#85479
Taskid: 2738082
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In preparation of test adaptation after introducing a new way to
seed test data, the fake model present on the m2x avatar employee test
has been registered to the model definitions instead of being
declared on it's test.
task-2792108
closesodoo/odoo#87665
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit the create_employee option was enabled by default
even from the employee's form view which would lead to a loop.
closesodoo/odoo#87670
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The group_public_id and group_id and subscription_department_ids
should only be used when the channel_type is 'channel'.
task-2766712
closesodoo/odoo#84813
Related: odoo/upgrade#3266
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Make sure related values are correctly propagated to the
resource.resource creation, and discard the inverse update post record
creation when it doesn't change anything
closesodoo/odoo#85601
Related: odoo/enterprise#25664
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* post onboarding notes in batch
* subscribe users in batch
* Only fetch the menu_hr_root data once, instead of once for each record
created.
Part-of: odoo/odoo#85601
After installing l10n_be_hr_payroll, the address, email, phone and bank account number take half of the dedicated space.
This commit makes the fields take the dedicated space
task-2790206
closesodoo/odoo#86098
Related: odoo/enterprise#25126
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To reproduce
============
- Connect with Mitchell Admin
- Go to Employee -> Settings and uncheck "Skills Management"
- Go to Settings -> Users, create a user "Test" and give him access to 2 companies (e.g. My Company [San Fransisco] and My Company [Chicago])
- Set current company to My Company [San Fransisco], go to Employees, create an employee record and associate it with your test user (in HR Settings tab)
- Set current company to My Company [Chicago] and create another employee and associate it with your test user too
- Connect as "test" user and go to my profile
- Try to change your langage (From English US to French) ==> Access rights error
Purpose
=======
When the `OnChange` is triggred we try to read the two employees linked to this user, but one of this employees is in unslected company
which leads to Access rights error.
Specification
=============
To solve the issue the domain in the security rule **Employee multi company rule** has been updated, where we added the condition
`('user_id', '=', user.id)` which gives the user the ability to read the needed data.
opw-2793123
closesodoo/odoo#87244
X-original-commit: 5916e15f6fa29fd89e12472b316475e757001945
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit the create_employee check box was always shown when
using the view_users_simple_form, it will now only show when the record
does not exist yet.
TaskId-2797251
closesodoo/odoo#86636
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Move model definition files from `models/thing/thing.js` to
`models/thing.js` and remove the now empty intermediate directory.
Task-2759582
* = calendar, crm_livechat, hr, im_livechat, mail_bot, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#86464
Related: odoo/enterprise#25291
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: calendar, hr, hr_holidays, im_livechat, mail, mail_bot, note, sms, snailmail,
website_livechat, website_slides.
This commit prepares the removal of beforeEach function in the
mail test suite. Cleanup was relying on beforeEach adding widgets,
components, unpatch method 'this'. We need to clean things up without
using either beforeEach or 'this'.
task-2792108
closesodoo/odoo#86526
Related: odoo/enterprise#25326
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The goal is to make it easier to link employees to users.
We can now directly create an employee from the 'invite' user form view
As well as create a new user from a form view using an action.
TaskId-2762247
closesodoo/odoo#85428
Signed-off-by: Kevin Baptiste <kba@odoo.com>
A Payroll tab needs to be added on the hr_job form as part of task-2693292.
This commit adds a name to the tab to be able to add the Payroll tab.
task-2693292
closesodoo/odoo#85270
Related: odoo/enterprise#24700
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: hr, hr_holidays, im_livechat, mail, snailmail, test_mail, website_livechat,
website_slides.
This commit will remove the need to duplicate models definition for
test purposes. Indeed, for now, we need to mock the model definitions
on the client side. Those models definitions are often very different
from the ones found on the server.
This approach will allow us :
- to ease model definitions during tests
- to get closer from the real models
task-2767820
closesodoo/odoo#84828
Related: odoo/enterprise#24486
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Expected Behaviour
When a user goes to his own profile, he has two ways to change his password :
1. through the 'Account security' tab
2. through the 'Actions' > 'Change password' menu in list/form view
Both option should let the user change its password, or one of the two should
not be present
Observed behaviour
While the first one works as expected, the second option gives an error as
the user doesn't have the admin rights
Reproducibility
This bug can be reproduced following these steps:
0. Make sure to have the "Employees" app installed
1. Connect as an employee (e.g. demo/demo on runbot)
2. Click on your name at the top right, go to 'My Profile'
3. Click 'Action' then 'Change password'
Problem Root Cause
There is an override of field_view_get for the res.users model in the hr
module which elevates the user with sudo so that the user may modify their
own user in some capacity. The problem is that by elevating the ACLs of the
user, fields_view_get will also return actions that are not normally
available to the user (e.g. deletion of user profile)
Related Issues/PR
- opw-2735671
closesodoo/odoo#86116
X-original-commit: 6487a9ea7d25d14a86a7476b4b512f3681da7405
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reorder smart buttons on the hr_employee to have them in the following order:
1. Documents
2. Holiday status
3. Time Off
4. Planning
5. Timesheets
6. Equipments
7. Cars
8. Contracts
9. Appraisal
10. Work Entries
11. Payroll
12. Attendance
13. Extra Hours
- Log in the chatter the name of the plan that has been started via the button "Launch Plan"
- When on mobile, open the Time Off Calendar in month view
- When sending a sms without any message, only display Message once in the invalid fields
- Avoid the sms-help info disappearing when clicking on it and there are characters in the body of the message
- Update the tooltip of phone number in the send sms wizard
- Avoid the employee name to be displayed on two lines on mobile if the name is too long. Reduce the font size instead
task-2735679
closesodoo/odoo#83745
Related: odoo/enterprise#23886
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Makes it possible to filter on My Team or My Department and search on
manager.
TaskId-2780061
closesodoo/odoo#85418
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
for example: in Europe/Brussels timezone, the presence
hour of an employee using this timezone is up with one hour.
The issue is that we give a localized time to format_time pretending
it's not (removing the tzinfo), so it's converted twice.
Specification
=============
To solve the issue, just give the time in UTC to format_time.
opw-2741634
closesodoo/odoo#85510
X-original-commit: 8953eb2e387bd046c586e815c10c1e30b00db13d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: calendar, hr, hr_holidays, im_livechat, note, sms, snailmail,
website_livechat, website_slides.
This commit prepares the ground for the model definitions PR.
In order to reduce the noise, all mail module's beforeEach
functions will be made async.
task-2767820
closesodoo/odoo#84845
Related: odoo/enterprise#24489
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: base_automation, hr, mail, web, web_tour, website_payment
Previously, some modules were imported twice, this increases duplication
and can make refactoring more difficult. This commit enables the
no-duplicate-imports eslint rule and fixes offending modules to remove
duplicates.
closesodoo/odoo#84530
Related: odoo/enterprise#24319
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
Some html field are not in their ideal style.
As the style for html fields is now dependent of
where you are in the xml view ( in group or not),
we have to adapt some views and flags some fields
to ensure they have the correct look.
This change is only be a visual enhancement
and should not prevent the function of said html fields
even if the views are not updated.
task-2637488
# Conflicts:
# addons/mail/wizard/mail_compose_message_views.xml
# addons/website_slides/views/slide_channel_views.xml
# Conflicts:
# addons/sale/views/sale_views.xml
closesodoo/odoo#83792
Related: odoo/enterprise#23911
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Previously for `appointment`, now for `appointment_hr`, the computation of
users' availability for appointment slots can be dependent on that person's
work schedule if:
* The user is linked to an employee
* The user's employee has working hours defined (resource calendar)
This commit provides working hours to all employees and a user to some, within
a multi-company setup.
Task-2728093
See odoo/enterprise#22642closesodoo/odoo#80688
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>