openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <944813@xxxxxxxxxxxxxxxxxx>]

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.

** Changed in: openobject-server
   Importance: Medium => Low

** Changed in: openobject-server
       Status: Confirmed => In Progress

** Changed in: openobject-server
    Milestone: None => 6.1

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/944813

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

Status in OpenERP Server:
  In Progress

Bug description:
  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 ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/944813/+subscriptions