[mav-adhoc]

Tarea: https://www.adhoc.inc/odoo/project.task/76597

Code migration of partner_creation_access from 19.0 to 20.0. Behaviour is
preserved; no functional change is intended.

What changes

Only the security file. In 20.0 ir.model.access and ir.rule are replaced by
ir.access, so security/ir.model.access.csv becomes security/ir.access.csv:

19.0  access_res_partner,res.partner.no.creation.user,base.model_res_partner,
      sales_team.group_sale_salesman,1,1,0,0

20.0  access_res_partner,res.partner.no.creation.user,res.partner,
      sales_team.group_sale_salesman,ru,

perm_read=1, perm_write=1 maps to ru. The two zeros are not lost: in 19.0
they did not restrict anything either, because access rights add up per group in
both versions. The xmlid is unchanged, so none is dropped and none is created.

No Python change was needed. Every symbol the module uses still exists in
20.0 with the same signature: @api.model_create_multi (now in
odoo/orm/decorators.py:318), self.env.su (odoo/orm/environments.py:61),
res.users.has_group (odoo/addons/base/models/res_users.py:1195), and the
four groups it references — base.group_partner_manager, base.group_public
(not replaced by the new base.group_everyone),
sales_team.group_sale_salesman (record identical between 19.0 and 20.0) and
base.group_portal.

depends and auto_install are unchanged. The license stays AGPL-3: no
dependency reaches Enterprise.

The README gains one paragraph stating something the module already does and
only a code comment explained: creations in superuser mode are not restricted
either. The i18n export realigns the terms shared with the core to their
es_419 wording; the module description is new in 20.0 (it is the README) and is
left untranslated on purpose.

Test plan

The module installs on a clean 20.0 database and its own tests pass
(0 failed, 0 error(s) of 2 tests).

Effective permissions on res.partner were compared at runtime between a 19.0
database and the migrated 20.0 one, granting each role on top of an internal
user, against a contact created by the superuser:

Role	19.0 read / write / create	20.0 read / write / create
salesman	yes / yes / no (UserError)	yes / yes / no (UserError)
partner manager	yes / yes / yes	yes / yes / yes
salesman + partner manager	yes / yes / yes	yes / yes / yes
internal user	yes / no (AccessError) / no (UserError)	yes / no (AccessError) / no (UserError)

Identical in all four rows. crm is not installed in either database, so the
salesman's write access comes from this module's own access row in both columns
— which is the direct evidence that the 1,1,0,0 to ru conversion kept the
permission.

To reproduce: install the module on a 20.0 database with base, contacts and
sale, create a user with base.group_user plus
sales_team.group_sale_salesman, and check that it can read and write any
contact but cannot create one.

Not covered by the tests

The module's two tests only cover the sudo path. Nothing asserts what the
module exists for, which is also the only file this migration touched: that a
salesman cannot create a contact, that a partner manager can, and that the
salesman keeps the write access granted by ir.access.csv. The runtime
comparison above verified it, but it does not live in the repo. Adding those
tests is follow-up work, not part of this migration.

Not verified

This was not tested against a database coming from a real upgrade: the upgrade
pipeline does not run the 19.0 to 20.0 jump yet, so CI does not exercise it
either.

[roboadhoc]

[les-adhoc]

@roboadhoc r+ nobump

[roboadhoc]

@mav-adhoc @les-adhoc because this PR has multiple commits, I need to know how to merge it:

• merge to merge directly, using the PR as merge commit message
• rebase-merge to rebase and merge, using the PR as merge commit message
• rebase-ff to rebase and fast-forward

[les-adhoc]

@roboadhoc rebase-ff

[roboadhoc]

Merge method set to rebase and fast-forward.