THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The use-case that motivated this fix is the deletion of a project task
with many subtasks. The field 'project_id' on tasks is recursively
computed, and some automated action must be executed when its value
corresponds to a given project.
The issue occurs when the domain of automated actions is evaluated by
method search(), because the latter flushes the fields to search on,
which are also the ones being recomputed. Combined with the fact that
recursive fields are not computed in batch, this leads to a huge amount
of recursive calls between the automated action and flush().
The execution of task.unlink() looks like this:
- mark 'project_id' to compute on subtasks
- delete task
- flush()
- recompute 'project_id' on subtask1
- call compute on subtask1
- in action, search([('id', 'in', subtask1.ids), ('project_id', '=', pid)])
- flush(['id', 'project_id'])
- recompute 'project_id' on subtask2
- call compute on subtask2
- in action, search([('id', 'in', subtask2.ids), ('project_id', '=', pid)])
- flush(['id', 'project_id'])
- recompute 'project_id' on subtask3
- call compute on subtask3
- in action, search([('id', 'in', subtask3.ids), ('project_id', '=', pid)])
- flush(['id', 'project_id'])
- recompute 'project_id' on subtask4
...
closesodoo/odoo#80141
X-original-commit: e2788b580ef15ef3083ac919737a46d850143832
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If some filter domains use M2O to models current user cannot access,
using sudo() permit to filter even when user cannot access linked
models.
for the accuracy of the fix, add a unit test which reproduce the exact
reported bug.
closesodoo/odoo#44923
X-original-commit: 30e2153539643491fad889811a54a8e580fa9c58
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose
=======
This module contains tests related to base automation. It makes no
sense as they have no business value.
Specification
=============
Move all the tests to a separate module as it contains models used only
to perform tests independently to functional aspects of other models.
Martin Trigaux