Odoo/odoo/addons/base/security/base_security.xml, branch 14.0 The current checkout of upstream Odoo [FIX] base: verify the rights on individual records too 2020-10-29T08:56:27+00:00 Martin Trigaux mat@odoo.com 2020-10-15T07:57:09+00:00 b0028c05d6ba9c67f16992ddb446eea6a854d099 The access rights of a model was checked but not the records themself. In case a user has access to a model but not to a specific record, he should not be able to execute a server action on it. Correct the ir.rule on private partners to be also verified for other operations than read. While it was not possible to actually write on it (due to side effects of ORM where write implies a read operation), check_access_rule('write') was working on a private address closes odoo/odoo#59740 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com> 
The access rights of a model was checked but not the records themself.
In case a user has access to a model but not to a specific record, he
should not be able to execute a server action on it.

Correct the ir.rule on private partners to be also verified for other
operations than read.
While it was not possible to actually write on it (due to side effects
of ORM where write implies a read operation),
check_access_rule('write') was working on a private address

closes odoo/odoo#59740

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
[IMP] base: Move the private address, group to technical category 2020-08-31T05:48:26+00:00 Nisha patel nit@odoo.com 2020-08-21T09:09:51+00:00 5f0ef2e36c33343a6beada36ef121de4b8767089 Currently, the access to private addresses group show in the other category in user form view and due to that it is visible in non-debug mode too. So in this commit, Move the private addresses group to tehcnical category so it should visible in debug mode only. closes odoo/odoo#56491 Task-id: 2318509 Related: odoo/enterprise#12646 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com> 
Currently, the access to private addresses group show in the other
category in user form view and due to that it is visible in non-debug
mode too.

So in this commit, Move the private addresses group to tehcnical
category so it should visible in  debug mode only.

closes odoo/odoo#56491

Task-id: 2318509
Related: odoo/enterprise#12646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
[ADD] base: API keys support 2020-08-14T23:03:27+00:00 Xavier Morel xmo@odoo.com 2019-05-22T14:12:33+00:00 d0dbbe23f4b1f797a9ed8c7a4726146d6df902ad * ability for a user to request / create keys associated to their user * overrides can block RPC solely through API keys, by overriding `_rpc_api_keys_only()` (to require API auth even in situations where the user has not requested it themselves) * hash keys just in case as we can do so and might as well, add a cleartext index (first 4 bytes of 20) to avoid blowing up the DB if a user decides to create millions of keys for some daft reason * users can delete their own keys, admins can delete (invalidate) anyone's keys * `scope` on API keys can be used to restrict usage to certain kind of applications, so API keys can be used for other things than global authentication. New keys manually created by users have no scope by default so they are valid everywhere (global keys). RPC auth (stateless XML-RPC/JSON-RPC) requires global keys Co-authored-by: Florimond Husquinet <fhu@odoo.com> Co-authored-by: Olivier Dony <odo@odoo.com> 
* ability for a user to request / create keys associated to their user
* overrides can block RPC solely through API keys, by overriding
  `_rpc_api_keys_only()` (to require API auth even in
  situations where the user has not requested it themselves)
* hash keys just in case as we can do so and might as well, add a
  cleartext index (first 4 bytes of 20) to avoid blowing up the DB if
  a user decides to create millions of keys for some daft reason
* users can delete their own keys, admins can delete (invalidate)
  anyone's keys
* `scope` on API keys can be used to restrict usage to certain
  kind of applications, so API keys can be used for other things
  than global authentication. New keys manually created by users
  have no scope by default so they are valid everywhere (global
  keys). RPC auth (stateless XML-RPC/JSON-RPC) requires global keys

Co-authored-by: Florimond Husquinet <fhu@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
 [ADD] base: enhanced security mode for users 2020-08-14T21:20:47+00:00 Xavier Morel xmo@odoo.com 2020-02-28T14:01:21+00:00 6e6946577307e569319661d413952f7b61bafd57 Similar to github's sudo mode, my understanding of the intent is to avoid third parties being able to perform sensitive / serious operations when leaving a logged-in machine unattended. This v1 only handles protecting "action methods" (methods called through buttons and intended to return action descriptors), although they can be used to "lock out" any methods they won't be able to prompt and the caller will likely be surprised. 
Similar to github's sudo mode, my understanding of the intent is to
avoid third parties being able to perform sensitive / serious
operations when leaving a logged-in machine unattended.

This v1 only handles protecting "action methods" (methods called
through buttons and intended to return action descriptors), although
they can be used to "lock out" any methods they won't be able to
prompt and the caller will likely be surprised.
 [IMP] *: remove global field definition in ir rules xml 2020-03-20T15:15:40+00:00 Victor Feyens vfe@odoo.com 2020-03-10T17:06:44+00:00 532c083cbbe0ee6e7a940e2bdc9c677bd56b62fa It is a computed field, there is no need to manually set its value. 
It is a computed field, there is no need to manually set its value.
[ADD] *: add ir.model.access on all transient models 2020-02-04T16:54:18+00:00 Martin Trigaux mat@odoo.com 2020-01-14T12:49:55+00:00 65530dfd6a0486f44134917f5cc42a2c30b95762 Following changes needing ir.model.access on transient models too. Remove groups declaration on the action to move it to ir.model.access when possible. Rules are strict by default with no unlink access by default and high priviledge asked. Adaptations may be needed later. Write access is given as a wizard may need to be modified in case the action triggers an error and the user has to correct a value account*: use account.group_account_user for all transient by default remove account.print.journal relic stock*: use stock.group_stock_user by default survey: survey user can send invitations mail: allow any employee to execute wizards additional verifications are made to ensure they are executed only on the documents the user has access to you give portal access to mail.compose.message as portal still does some actions like posting messages on the forum add ir.rule to avoid reading somebody else messages increase the query count because of undeterminist count crm: saleman for lead2opp, manager for massmailing partner manager for actions linked to partners avoid a write in test_lead_lost sms: any employee can send sms mrp: mrp user can execute wizards give unlink access as making write during do_produce operation base_import: employees can import files delivery: stock user can deliver event_sale: sale user can configure the wizards event user inherit from sale rights gamification: employee can give badge google_service: resolve FIXME hr: add specific rights manager can set a plan according to group on button anyone who can write on an employee can register a departure hr_expense: set rights based on buttons hr_holidays: an approver can make a summary report hr_recruitment: recruiter can refuse a candidate hr_timesheet: can use the wizard if can create a timesheet l10n_eu_service: managers can create fiscal positions mass_mailing: same group as on mass.mailing.list membership: accountant can create invoice from membership payment: accountant can create a link as the source is an account.move keep the payment.acquirer.onboarding.wizard to system user only as it is called during company configuration point_of_sale: PoS manager only can use wizards never create closing_balance_confirm_wizard records product_expiry: stock user has rights on stock.picking product_margin: access from accounting menus repair: same rules as for above models sale: set ir.rule for self wizard only add rule from model introduced in payment to add salesman group sale_crm: saleman can create a quotation from a lead sale_coupon: any saleman can generate coupon add self ir.rule sale_product_configurator: salesman can select product variants snailmail: employee can send letters website: designers can write on website website_crm_partner_assign: same rule as group on action website_sale: sale ACL as for payment.acquirer.onboarding.wizard website_slides: anyone can send invitation base: base.language.*: allow employee (cf lang_install) change.password.user: can not read change password wizard of other users test.*: no access is needed Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review of acl 
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value

account*: use account.group_account_user for all transient by default
	  remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
      additional verifications are made to ensure they are executed
      only on the documents the user has access to you
      give portal access to mail.compose.message as portal still does
      some actions like posting messages on the forum
      add ir.rule to avoid reading somebody else messages
      increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
     partner manager for actions linked to partners
     avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
     give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
	    event user inherit from  sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
    manager can set a plan according to group on button
    anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
	 as the source is an account.move
	 keep the payment.acquirer.onboarding.wizard to system user
	 only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
	       never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
      add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
	     add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation

base: base.language.*: allow employee (cf lang_install)
      change.password.user: can not read change password wizard of
      other users
      test.*: no access is needed

Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
[FIX] base: don't hide internal users behind rules 2020-01-13T10:51:01+00:00 Damien Bouvy dbo@odoo.com 2020-01-13T08:24:22+00:00 39c00a28df1dad4a4b02653c66a2f72d9cc55e06 Example: User 1 has access to company A User 2 has access to company B Customer 1 is shared, has user 2 as their Salesperson Try to create a SO for Customer 1 as User 1 => access rights issue, the quote is trying to set User 2 as the salesman of the quote but cannot because of base.res_users_rule This commit makes this flow possible by sharing users if they're not portal. closes odoo/odoo#43190 X-original-commit: ebc8d85d383643c1d4d2aa6723bc7a589c7d1c68 Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com> 
Example:
  User 1 has access to company A
  User 2 has access to company B
  Customer 1 is shared, has user 2 as their Salesperson
  Try to create a SO for Customer 1 as User 1
      => access rights issue, the quote is trying to set User 2
	 as the salesman of the quote but cannot because of
	base.res_users_rule

This commit makes this flow possible by sharing users
if they're not portal.

closes odoo/odoo#43190

X-original-commit: ebc8d85d383643c1d4d2aa6723bc7a589c7d1c68
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
[FIX] base: better multi-company rules for partners 2020-01-02T13:31:28+00:00 Damien Bouvy dbo@odoo.com 2019-12-30T16:24:20+00:00 bd5305a51b9a264b971961aebbdc3e79590e4ad9 Commit d86c2c5883 removed the multi-company partner rule because it interfered with the users rule. Indeed, interference between the user's default company and its corresponding partner's company made it possible to have users that were basically unselectable in relational fields if you were not viewing more than one company at the same time. However, this generates a lot of frustrations and tickets for Odoo users, since having everything shared by default is annoying and a clear departure from the expected behaviour. This commit tries to mitigates this fix's side-effects by re-introducing the multi-company rules but by not applying it to partners who are linked to a non-share user (basically, any partner who has a user that is not a portal user). That way, customers and vendors remain filtered by the multi-company rules and only partners of internal users bypass the rule. This is still a side-effect, and might raise a few eyebrows (why is this partner visible even though it is in another company?), but the trade-off seems to be worth it since it fixes the original issue with a far smaller behaviour change. Fixes #41720. closes odoo/odoo#42592 X-original-commit: 2390ba60b8bd624daaea2e6d4e3fd85ef1b1faeb Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com> 
Commit d86c2c5883 removed the multi-company partner rule because it
interfered with the users rule. Indeed, interference between the user's
default company and its corresponding partner's company made it possible
to have users that were basically unselectable in relational fields if
you were not viewing more than one company at the same time.

However, this generates a lot of frustrations and tickets for Odoo
users, since having everything shared by default is annoying and a clear
departure from the expected behaviour.

This commit tries to mitigates this fix's side-effects by re-introducing
the multi-company rules but by not applying it to partners who are linked
to a non-share user (basically, any partner who has a user that is not
a portal user). That way, customers and vendors remain filtered by the
multi-company rules and only partners of internal users bypass the rule.
This is still a side-effect, and might raise a few eyebrows (why is this
partner visible even though it is in another company?), but the
trade-off seems to be worth it since it fixes the original issue with a
far smaller behaviour change.

Fixes #41720.

closes odoo/odoo#42592

X-original-commit: 2390ba60b8bd624daaea2e6d4e3fd85ef1b1faeb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
[FIX] base: res_users in multi company 2019-10-01T13:42:50+00:00 Arnold Moyaux arm@odoo.com 2019-10-01T12:58:03+00:00 d86c2c588367dee319649ab2a5890975c1bcb916 Usecase to reproduce: - User1 in company A and company B (default company A) - User2 in company A and company B (default company A) As user1 select company B in company switcher. -> You never see user2 as he's hidden by a record rule. This issue was present in older version when disabling the “Common Contact Book” feature, because it was then enabling the faulty record rule. Since [1], this faulty record rule is always enabled. (Note that res.partner record rules are applied to res.user through _inherits) We chose to remove the faulty record rules so that the present usecase is now working, but the drawback is that you now see partners from other companies. Also remove [2] that try to fix the issue and become useless if the rule is removed. [1] commit 25714692b23624d04a43862db26ebcf802b89399 [2] commit d6c65aa4d48ae2bf10830e04a3fb043b06816277 closes odoo/odoo#37712 Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com> 
Usecase to reproduce:
- User1 in company A and company B (default company A)
- User2 in company A and company B (default company A)

As user1 select company B in company switcher.
-> You never see user2 as he's hidden by a record rule.

This issue was present in older version when disabling the “Common Contact Book” feature,
because it was then enabling the faulty record rule. Since [1], this faulty record rule is
always enabled.
(Note that res.partner record rules are applied to res.user through _inherits)

We chose to remove the faulty record rules so that the present usecase is now working,
but the drawback is that you now see partners from other companies.

Also remove [2] that try to fix the issue and become useless if the
rule is removed.

[1] commit 25714692b23624d04a43862db26ebcf802b89399
[2] commit d6c65aa4d48ae2bf10830e04a3fb043b06816277

closes odoo/odoo#37712

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
[FIX] base: allow users to read themselves in multicompany 2019-08-28T13:47:39+00:00 RomainLibert rli@odoo.com 2019-08-28T13:22:03+00:00 d6c65aa4d48ae2bf10830e04a3fb043b06816277 You should always be able to read your own user whatever the company you are logged into closes odoo/odoo#36190 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com> 
You should always be able to read your own user whatever the company you
are logged into

closes odoo/odoo#36190

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>