can't access some user object once user has changed company

[Valentin Lab]

ISSUE:

We are using ``project`` module, and have 2 company's registered in OpenERP (6.1 final).

When a user creates a task in a company, then changes their default company in their profile settings, other users registered only in the first company are unable to access the form view of the task. They receive a:

"Access Error" on operation "read" on document type "Users"

Although we can check that the task is correctly registered to be in the first company.
Notice that also, it's on "Users" that the AccessError is triggered and not Tasks...

MORE INFORMATION:

After looking deeper, it seems that "ir_rules" are involved in checking that current user is authorized to view the "res.users" record that describes the creator of the task. Information on the project.task creator is needed probably to display it's name.

The rule (in "ir_rules") concerning "res.users" object is set by default to this value (as of lp:openobject-server rev 4072):

in base/res/res_security.xml:

  ['|',('company_id.child_ids','child_of',[user.company_id.id]),('company_id','child_of',[user.company_id.id])]

Which will use "company_id" of the target user to check if we can access his "res.user" record.

If using "company_id" attribute makes sense in other objects as "project.tasks" to decide if a user can see it, it seems to me that it has a different meaning in "res.users" objects: it's the last context value of this user. It's some sort of a personnal configuration that shouldn't be used to check for granting permissions to other users to get access to my res.users record.

Instead, what seems important is to check "company_ids" (with a final 's') which list all companies in which this user is registered as a member.

My proposition would be to put something like this:

  [('company_ids', 'child_of', user.company_id.id)]

Any comments ?

[Valentin Lab (vaab)]

there's the patch mentionned in the description changing 'force_domain' value to proposed value in base/res/ir_security.xml

[Jignesh Rathod(OpenERP) (jir-openerp)]

Hello Valentin Lab ,

I have checked this issue at my end with latest trunk as well as 6.1,
But I did not face any access error as you mention in bug report.
So would you please provide more information regarding this issue.

I have attached a video for more reference.

Correct me If I am wrong..

Thanks and waiting for reply!

[Valentin Lab (vaab)]

Thanks for the answer. I viewed your video which -- I'm afraid -- doesn't illustrate the bug case as I tried to explain.

What you show in your video is that viewing the form view of a task that is assigned to you will work. (correct me if i'm wrong).

What triggers the bug, is to try to view a task that is assigned to somebody ELSE (let say Bob) which is in the same company as you.
The additional trick, is that Bob must have changed his active company in his profile before you try to view the task.

Here are the steps:
- Making test environnement
    - Create Alice and Bob in the Users
    - Create Microsoft and Apple
    - Alice works at Microsoft, and Bob work at Microsoft AND Apple (he's a lucky guy)
- Test routine:
    - Bob creates a task "Fix that blue screen" while logged in company Microsoft.
    - Bob, then, changes his profile to switch to Apple company.
    - OPTIONAL: For the purpose of the test, he may de-log and let Alice log in.
    - Alice wants to view the Task view form of the task "Fix that blue screen"

Can you repeat it ? Is it clearer ?

As a reminder, also please avoid using "Administrator" as "Alice" role, as ir_rules permissions are not applied to administrator
because:

_compute_domain(...) will have
  ...
  if uid == SUPERUSER_ID:
            return None
  ...

which bypasses any ir_rule permission checks.

[Valentin Lab (vaab)]

This issue is deepest and subtlest than I originally thought. I'm looking to make a video answer to get a full reproducable video.

It seems that my precedent steps are not sufficient to trigger the bug. So don't bother answering until I post back a video demonstrating the bug.

Sorry for the inconvenience if any.

[Valentin Lab (vaab)]

Here we are with a video response... Sorry for my terrible accent and the bad sound recording. Nevertheless, I think you'll be able to use this to get some valuable information on that bug.

An important information that was added in the video, is that you need "project_mailgate" module installed before following the process with Alice and Bob described before.

Please note that this module will uncover the bug, but I've seen it occuring also with other modules (ie: "document" was failing also, but I couldn't manage to reproduce it from scratch).

[Amit Parik (amit-parik)]

Hello Valentin,

Thanks for your nice explanation and useful video.
Now we can produced it same at our end.

Thank you!

[Olivier Dony (Odoo) (odo-openerp)]

Hello Valentin,

Thanks for the very detailed bug report and the proposed solution. This is a complicated technical issue (like all things multi-company) so the solution needs to be considered carefully. Let me try to elaborate on this...

The purpose of multi-company "record rules" is to enforce cross-company visibility rules for 2 main reasons:
 1. Preventing users from seeing records that they are not supposed to see according to the access control policy of the companies.
 2. Ensuring that users will see a consistent set of records in any circumstances.

This is why users not only have a list of "allowed companies" (company_ids) but must also chose a "main company" at any given time.
You've seen the warning when this field changed in user preferences: immediately the user will start seeing only records that are available within the "main company", regardless of her right to see data from other companies. If we allowed users to see at all times the record of all companies they're allowed to choose it would become near impossible to work for them: they would constantly risk mixing records from different companies, making documents that are inconsistent and would cause problems later. As a result, we never use the "company_ids" field in record rules, even if it would look "semantically" more correct.

Now I agree that users are a bit different from other kinds of records because they can change from one company to another at any time, so it does not really make sense to prevent selecting/reading a certain user because she has just changed her preferences to view a different company. In that sense your patch is correct. However I'm not sure it is sufficient: what about the case where Bob switches to company "Apple" permanently after creating the task and the admin restricts his "allowed companies" to only "Apple". Should Alice be again prevented from reading it, even though this task properly belongs to her company (company of task is set at creation)?
Normally we always try to allow viewing (not necessarily changing) all fields on a record that you have the right to see. That's the reason why you could not reproduce this issue with only the "project" module, even if the Bob has switched to Apple, Alice can still see the task and the "assigned to" field that is set to Bob.
This works by temporarily bypassing access rules when reading the labels of direct relationships from the main record for which access is granted (technically the `name_get` calls).
I think we need to use the same technique here, and make sure that the user can always access the message history for a task that she can see, regardless of the company currently selected by the messages' authors.

PS: Another important thing to keep in mind is that every multi-company environment is different, and it is necessary to review all "record rules" during the configuration of a multi-company database, to fine-tune them according to the desired data sharing policy. This is the reason why I'm downgrading this issue as Low priority, as it could almost be considered a simple configuration issue.

[Olivier Dony (Odoo) (odo-openerp)]

The two parts of this issue discussed in comment #8 should now be fixed after the following changes:
- 6.1 server branch, rev. 4114 rev-id: <email address hidden> (credited to Valentin Lab)
- 6.1 addons branch, rev. 6684 rev-id: <email address hidden>

Thanks for reporting and providing a patch!