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 test `test_employee_create_from_signup` was failing when the module
`auth_signup` was installed because of the missing partner.
closesodoo/odoo#107243
X-original-commit: 2688f9bb00f9cb049ff11bbe4443adc66ee05941
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
The res.users model functions a bit uniquely since it should allow a user to
modify their own parameters but turns off model edition priviledges by default.
See "SELF_WRITEABLE_FIELDS".
This implies that ir_ui_view#_postprocess_access_rights method will by default
turn off record edition, by automatically adding a 'edit="false"' attribute on
the form node when the frontend calls 'get_views'.
This will in turn prevent the user from modifying its preferences as it will
set the form view in readonly mode.
(It was apparently ignored pre-OWL, hence why we only have this issue now).
To fix the issue, we force the edition by manually setting 'edit="1"' on our
"view_users_form_simple_modif" form.
Allowing the end-user to modify their own settings again.
A tour was added to ensure this behavior.
Note that tour steps need to be adapted in the 'hr' module, as this module
changes the flow of modifying user preferences.
Task-3067001
closesodoo/odoo#106440
X-original-commit: 490d480458590c205962c3f9b95a63790a59f4d3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Detailed Reason field in hr_departure_wizard view is now wrapped in a group for better organization.
task-3002105
closesodoo/odoo#106304
X-original-commit: 824f62c59fd4408b1460826c2b0f0732bd10c2fd
Related: odoo/enterprise#34282
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The job_title field was too narrow and misaligned on mobile.
Removed the help text for the Contacts smartbutton.
task-3070980
closesodoo/odoo#106240
X-original-commit: 37fcdb0c105674ae0f45461c85668ed0b0ee2922
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The purpose of this commit is to add extension points that allow code
to be executed before and after the save of a record.
CallBack:
onWillSaveRecord is a callBack that will be executed before the
record save if the record is valid if the record is valid.
If it returns false, it will prevent the save.
onRecordSaved is a callBack that will be executed after the save
if it was done. It will therefore not be executed if the record
is invalid or if a server error is thrown.
This commit will replace all the save overrides by the onWillSaveRecord
and onRecordSaved callBack.
Observed problem:
We could notice that each of the overrides of save in order to execute
for example a doAction after this one did not take into account the fact
that the save did not succeed.
For example, a required field is invalid and we try to save, then the
doAction will be executed without the "write" of the save.
The callBack onRecordSaved will prevent this common error.
closesodoo/odoo#105180
Related: odoo/enterprise#33710
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to avoid the execution of code depending
on the validity of the save of a Record.
Before this commit, several override save functions in Record execute
code after the record's save without checking if the record's save has
taken place.
Override before:
export class NewRecord extends Record {
async save() {
const isSaved = await super.save(...arguments);
// doAction
return isSaved;
}
}
Override after:
export class NewRecord extends Record {
async save() {
const isSaved = await super.save(...arguments);
if (isSaved) {
// doAction
}
return isSaved;
}
}
How to reproduce the problem:
Go to a form view with a Record having its save override function.
Edit a record in such a way to have an invalid field
Click on the save button
Before this commit:
The doAction is executed
After this commit:
The doAction is not executed
Real use case
- Go to the form view of a lead in CRM
- Change stage
- Clear the name field
- Click on save button
Before this commit:
A call to get_rainbowman_message is made
After this commit:
No call to get_rainbowman_message is made.
closesodoo/odoo#105687
X-original-commit: 46b93da545b52496196624712c44599fd6467f4e
Related: odoo/enterprise#33913
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
Purpose
=======
Notify HR when an employee changes their own info and check that everything is logged on the chatter
closesodoo/odoo#102069
Taskid: 3029662
Related: odoo/enterprise#32253
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The presence bubble on the employee form is hidden while it is shown on the kanban view of the employees.
This commit fixes the presence bubble to have a consistent behaviour between the employees kanban view and the employee form.
task-2945615
closesodoo/odoo#103884
X-original-commit: f26f2356ecfcc293bbc6c844882b40a58c21062f
Related: odoo/upgrade#3985
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
Remove the call to `t-on-click` in the arch of form/kanban views as it
crashes when the view is opened in studio.
Instead use a dedicated `<widget>`.
closesodoo/odoo#103820
X-original-commit: 2a213a150b4421ce4da32db754651cfc41adbef4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The label was above the profile picture and the employee name below it.
closesodoo/odoo#103690
X-original-commit: d6e5aee5ba242a7524e17fd7f9d1a55c3d25df7a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- set demo to receive notifs in Odoo
- go to employees
- click "launch plan" for demo user
- login as demo user
- Click on the link for the activity that is sent in discuss
Issue:
There is no chatter in the view
Explanation:
the view of en employee coming from messaging is always
hr.employee.public that does not contain the chatter.
opw-2990577
closesodoo/odoo#102851
X-original-commit: 93b95317315a1ba70ce0331c63321ab8eaa487d3
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps :
- On a new DB (no demo data). Say created at 15:00. - Go to planning.
- Add a shift for today.
- Set the dates from 08:00 to 17:00.
Issue :
The 'Allocated Time' = 02:00.
Cause :
We used to count from the resource creation min to the departure max. So, in this case, not from 08:00, but from 15:00.
While this might seem logical, it confuses users in onboarding.
Fix :
Calculate the whole time, regardless of the resource lifespan.
Notes :
- Similar issues solved with this commit :
> Once the shift validated, the avatar progress bar uses
the same allocated time.
> Same in Project Task gantt view.
- When contract is installed, if the resource does not have a contract, the Allocated Time = 0. Now, it is calculated from the resource calendar.
task-2983993
closesodoo/odoo#102732
X-original-commit: 6a61d1c4c56075ade36f6f32e7a61f1f6c771a6f
Related: odoo/enterprise#32547
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The current homeworking module doesn't answer the standard of quality.
For now It will be removed from the settings and app store so it is not visible
to any users. It will return after it has been reviewed and improved.
task-2995332
closesodoo/odoo#102602
X-original-commit: b3ad588699714052b0010a599be76d1922a7ced1
Related: odoo/enterprise#32483
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, only when using the save button on the profile, the
context is reloaded with the new language. If we use the breadcrumb to
exit the profile view, the new language is saved, but the context is not
reloaded.
closesodoo/odoo#102493
X-original-commit: 41b2ca93f1fc6402ff5d88b7dd8af175dd49ac6d
Related: odoo/enterprise#32432
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The "Reporting" title was not properly displayed (stuck to the left of
the dropdown) and the Timesheets entry was not displayed as a proper
dropdown item.
task-3001445
closesodoo/odoo#102351
X-original-commit: 250809a201386cfb1d2ba52d3911bd765a2c910a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The goal of this commit is to fix the behaviour of clicking on a field
with the "many2one_avatar" widget in a list view.
Expected behaviour when clicking on a field with the "many2one_avatar" widget:
- Editable list view: switch row to edit
- Multi_edit list view with selected record: switch row to edit
- Other case: open the many2one_avatar record in a form view
Before this commit, clicking on a field with the "many2one_avatar" widget always
opens the record in a form view.
After this commit, the expected behaviour when clicking on a field with
the "many2one_avatar" widget is respected.
closesodoo/odoo#102146
X-original-commit: ad597d414c59723d3c6af5dfdc1a3a41fd4f4032
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Set the default value for create_employee to False.
When coming from employee form, hide the create_employee field.
task - 2990426
closesodoo/odoo#100661
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Model patches are now defined using the `registerPatch` function. This
function takes an object as argument which keys match those of a model
definition.
Benefits:
+ More consistent shape between model definitions and patch definitions
+ No need to import one function to each type of patch
+ No need to repeat the model name for each type of patch
+ No need to import the original definition
Task-2998282.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#101827
X-original-commit: 7d23491b44b7372209057ea2abc565a95710b316
Related: odoo/enterprise#32136
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since commit ae7bd570e13fe19367f86a1519b23747b3b0b73e, the size of
`o_work_employee_main` has been reduced.
This commit fixes this issue.
task-2918464
X-original-commit: 99d13b4b3a5efabff9f71f0cfe1b9cf72bb47ccd
Part-of: odoo/odoo#101655
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>
The domain of `work_location_id` requires the company_id and address_id
which were missing from the tree view, showing a traceback when trying
to change that field.
closesodoo/odoo#101195
X-original-commit: 8376adc197208490bf3e4ce0ddbdb6f8e1ae6c60
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Not all employees have a company car. This commit adds a private license plate field on hr.employee.
The field allows the HR Officer and HR Administrator to search for emloyees based on their license plates.
If fleet and hr apps are installed, the search is based on both the company car and private car license plates.
task-2936873
closesodoo/odoo#101146
Related: odoo/enterprise#31796
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Some views still use them.
closesodoo/odoo#101081
X-original-commit: adb5508afd2749dbbfeb85803d707df43358b011
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When installing l10n_mx, a error occurs
Traceback (most recent call last):
File "/data/build/odoo/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-15>", line 2, in new
File "/data/build/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/data/build/odoo/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/data/build/odoo/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/data/build/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/data/build/odoo/odoo/modules/loading.py", line 206, in load_module_graph
registry.setup_models(cr)
File "/data/build/odoo/odoo/modules/registry.py", line 289, in setup_models
model._setup_fields()
File "/data/build/odoo/odoo/models.py", line 3294, in _setup_fields
field.setup(self)
File "/data/build/odoo/odoo/fields.py", line 512, in setup
self.setup_nonrelated(model)
File "/data/build/odoo/odoo/fields.py", line 4524, in setup_nonrelated
m2m = model.pool._m2m
AttributeError: 'Registry' object has no attribute '_m2m'
Since #99438 hr is sintalled automatically
This means that when doing a -i l10n_mx, hr is installed too
hr will conditionnaly call a button_immediate_install in this case.
What's going on after that: It's a mess
button_immediate_install will create another registry
This registry will be present on some models that will ne used later
by the initial registry creating the missing _m2m case
For the record, here are some of the strange and key element during
the install
2022-09-21 16:31:27,691 2579263 INFO test_mx odoo.modules.loading: loading 1 modules...
2022-09-21 16:31:27,691 2579263 INFO test_mx odoo.modules.loading: Loading module base (1/1)
...
2022-09-21 16:31:36,222 2579263 INFO test_mx odoo.modules.loading: Module base loaded in 8.53s, 8902 queries (+8902 other)
2022-09-21 16:31:36,222 2579263 INFO test_mx odoo.modules.loading: 1 modules loaded in 8.53s, 8902 queries (+8902 extra)
2022-09-21 16:31:36,240 2579263 INFO test_mx odoo.modules.loading: updating modules list
2022-09-21 16:31:36,241 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.update_list on [] to user __system__ #1 via n/a
2022-09-21 16:31:36,943 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Mexico - Accounting'] to user __system__ #1 via n/a
...
2022-09-21 16:31:49,775 2579263 INFO test_mx odoo.modules.loading: Loading module base_install_request (26/78)
...
2022-09-21 16:31:50,043 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Project', 'Email Marketing', 'Employees', 'Knowledge', 'Sign', 'Planning', 'Appointments', 'Surveys'] to user __system__ #1 via n/a
2022-09-21 16:31:50,167 2579263 INFO test_mx odoo.modules.loading: Module base_install_request loaded in 0.39s, 228 queries (+228 other)
...
2022-09-21 16:32:10,816 2579263 INFO test_mx odoo.modules.loading: Loading module l10n_mx (55/78)
...
2022-09-21 16:32:17,618 2579263 INFO test_mx odoo.modules.loading: Module l10n_mx loaded in 6.80s, 4302 queries (+4332 other)
...
2022-09-21 16:32:50,371 2579263 INFO test_mx odoo.modules.loading: Loading module hr (35/112)
2022-09-21 16:32:57,594 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_immediate_install on ['Employees - Mexico'] to user __system__ #1 via n/a
2022-09-21 16:32:57,594 2579263 INFO test_mx odoo.addons.base.models.ir_module: User #1 triggered module installation
2022-09-21 16:32:57,595 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Employees - Mexico'] to user __system__ #1 via n/a
...
2022-09-21 16:32:58,558 2579263 ERROR test_mx odoo.modules.registry: Creating Registry <odoo.modules.registry.Registry object at 0x7f02cc0e8130>
Stack (most recent call last):
File "/home/xdo/osrc/master/odoo/odoo-bin", line 8, in <module>
odoo.cli.main()
File "/home/xdo/osrc/master/odoo/odoo/cli/command.py", line 56, in main
o.run(args)
File "/home/xdo/osrc/master/odoo/odoo/cli/server.py", line 179, in run
main(args)
File "/home/xdo/osrc/master/odoo/odoo/cli/server.py", line 173, in main
rc = odoo.service.server.start(preload=preload, stop=stop)
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1391, in start
rc = server.run(preload, stop)
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 570, in run
rc = preload_registries(preload)
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-15>", line 2, in new
File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 248, in load_module_graph
getattr(py_module, post_init)(cr, registry)
File "/home/xdo/osrc/master/odoo/addons/hr/__init__.py", line 19, in _install_hr_localization
l10n_mx.button_immediate_install()
File "<decorator-gen-74>", line 2, in button_immediate_install
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
return method(self, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 486, in button_immediate_install
return self._button_immediate_function(type(self).button_install)
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 607, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "<decorator-gen-15>", line 2, in new
File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 79, in new
registry.init(db_name)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 115, in init
_logger.error(self, stack_info=True)
2022-09-21 16:32:58,580 2579263 INFO test_mx odoo.modules.loading: loading 1 modules...
2022-09-21 16:32:58,581 2579263 INFO test_mx odoo.modules.loading: Loading module base (1/1)
...
2022-09-21 16:33:35,294 2579263 INFO test_mx odoo.modules.loading: Loading module base_install_request (30/85)
...
2022-09-21 16:33:35,745 2579263 INFO test_mx odoo.modules.loading: Module base_install_request loaded in 0.45s, 131 queries (+131 other)
...
2022-09-21 16:34:05,789 2579263 INFO test_mx odoo.modules.loading: Loading module l10n_mx (62/85)
...
2022-09-21 16:34:28,497 2579263 INFO test_mx odoo.modules.loading: Loading module hr (35/113)
...
2022-09-21 16:34:32,067 2579263 INFO test_mx odoo.modules.loading: Module hr loaded in 3.57s, 4092 queries (+4092 other)
2022-09-21 16:34:32,067 2579263 INFO test_mx odoo.modules.loading: Loading module link_tracker (37/113)
...
2022-09-21 16:34:32,690 2579263 INFO test_mx odoo.modules.loading: Module link_tracker loaded in 0.62s, 267 queries (+267 other)
...
2022-09-21 16:35:04,063 2579263 INFO test_mx odoo.modules.loading: Modules loaded.
2022-09-21 16:35:04,068 2579263 INFO test_mx odoo.modules.registry: Registry loaded in 125.514s
2022-09-21 16:35:04,068 2579263 INFO test_mx odoo.addons.base.models.ir_module: getting next ir.actions.todo()
2022-09-21 16:35:04,071 2579263 INFO test_mx odoo.addons.base.models.ir_module: next action is "Open Menu"
2022-09-21 16:35:04,094 2579263 INFO test_mx odoo.modules.loading: Module hr loaded in 133.72s, 4344 queries (+81420 other)
...
2022-09-21 16:35:04,094 2579263 INFO test_mx odoo.modules.loading: Loading module link_tracker (37/112)
2022-09-21 16:35:04,163 2579263 ERROR test_mx odoo.modules.registry:
setuping model: ir.model.fields()
registry on model: <odoo.modules.registry.Registry object at 0x7f02cc0e8130>
registry calling setup_models: <odoo.modules.registry.Registry object at 0x7f02e92399d0>
2022-09-21 16:35:04,164 2579263 WARNING test_mx odoo.modules.loading: Transient module states were reset
2022-09-21 16:35:04,165 2579263 ERROR test_mx odoo.modules.registry: Failed to load registry
2022-09-21 16:35:04,165 2579263 CRITICAL test_mx odoo.service.server: Failed to initialize database `test_mx`.
Traceback (most recent call last):
File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-15>", line 2, in new
File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 206, in load_module_graph
registry.setup_models(cr)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 293, in setup_models
model._setup_fields()
File "/home/xdo/osrc/master/odoo/odoo/models.py", line 3294, in _setup_fields
field.setup(self)
File "/home/xdo/osrc/master/odoo/odoo/fields.py", line 512, in setup
self.setup_nonrelated(model)
File "/home/xdo/osrc/master/odoo/odoo/fields.py", line 4524, in setup_nonrelated
m2m = model.pool._m2m
AttributeError: 'Registry' object has no attribute '_m2m'
Naive fix here: use button_install instead of button_immediate_install
(not even sure this is 100% correct)
All calls to button_immediate_install should be fixed maybe to avoid
a registryloadingception
closesodoo/odoo#100909
X-original-commit: 919c1f362b1c26dbd04b0501c4d63e2929fb8df4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit [1], we use base.main_company as default value for the
address of the admin employee. This is not correct as base.main_company
is referring to res.company model while address_id is expecting a
res.partner id.
This works in most default situations as id = 1 is the same for both
res.company and res.partner, but not anymore in case we have merged
the initial partner with another one.
We should use base.main_partner instead of base.main_company.
[1]:https://github.com/odoo/odoo/commit/c0ca736193df42814389151956eb07c28c77d18eclosesodoo/odoo#100883
X-original-commit: 163167052cd904db2ca2ea4322469a066c095938
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
*: hr, im_livechat, snailmail, website_livechat
This commit introduces the public livechat bundle, which
contains the models that are specifically used in public livechat.
Doing so reduces the amount of model and data in frontend and
external lib, which makes the page load faster.
Task-2990182
Task-2990191
closesodoo/odoo#100768
Related: odoo/enterprise#31608
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prefer using hooks instead.
Makes use of the new open_chat_hook from mail when possible.
closesodoo/odoo#100764
X-original-commit: d058734cf55f2c3f46f2f23e0bbbfc54f2f0da15
Related: odoo/enterprise#31605
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Those fields may be used in the new views.
Some of the legacy fields had to be kept because they are used
in some legacy views, more notably the gantt and activity views as well
as in the mrp work order tablet mode.
X-original-commit: 1c871ad9ea4a77468911ff6a5546688a26398a8b
Part-of: odoo/odoo#100764
The presence icon was bigger than the chat one.
Now they are better aligned with the employee's name.
closesodoo/odoo#100564
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Fields param is actually not a kwargs. This cause a stack trace when opening a chat window (other than a chat with yourself) from a Kanban user avatar icon.
closesodoo/odoo#100315
X-original-commit: 95d3f4b0ea4dd5f1f9403b6e5ba97e1e2a510f65
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
There was an extra `r` in the name of the super method called, which
produces a traceback.
closesodoo/odoo#100361
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
FrancoisGe