Displaying records (eg. sale orders) for multiple companies in one tree view

[thomaspaulb]

From the wiki of the project I have understood that one of the objectives of this project is, and I quote:

Security rules: A user should be able to display all the data for the companies he is allowed to operate on, not on the basis of the current company.

I have tested first 10.0 and then the more recent 11.0 branch of the modules, but if I am in company A, I can only see and create records for company A, and not B. Unless I am the Administrator user, which by default can read all records of course.

Is this feature "just not implemented yet" or is it something that you achieve in a different way, eg. by using company groups? Or is there some setting or trick that I have not found yet? Or is this part supposed to be done in customer-specific security modules, which decide on a per-customer basis which records are shared and which are not?

This behaviour is important to us, since the main reason for me / our users to start using these modules is because there are some users who work on multiple companies at the same time, and they want to do so without continuously switching, which of course is only possible if they can see the records.

[thomaspaulb]

@jbeficent Would you know the answer to this?

[etobella]

Is company b a child of A. This should work if the second company is chils of your current company

[thomaspaulb]

@etobella Yes, this is an option, although when I create parent company "A" with childs "B" and "C", and I let users work in "A", I actually dont want them to work in A but by default in B and with the option of working in C. A is just a dummy company. However, for example when I generate an invoice from a sale order, it will try to place the booking in the journal of company "A", since it's the one selected - all of those things would need to be overridden.

Proposal: modifying all multicompany rules to be "in user.company_ids" instead of "child_of user.company_id". Would that be better / worth an effort as a PR?

[JordiBForgeFlow]

That is precisely what Odoo is going to do for v13. We did not consider it, but I think that it's a good aproach. El vie., 19 jul. 2019 17:27, Tom <notifications@github.com> escribió:

…

@etobella <https://github.com/etobella> Yes, this is an option, although when I create parent company "A" with childs "B" and "C", and I let users work in "A", I actually dont want them to work in A but by default in B and with the option of working in C. A is just a dummy company. However, for example when I generate an invoice from a sale order, it will try to place the booking in the journal of company "A", since it's the one selected - all of those things would need to be overridden. Proposal: modifying all multicompany rules to be "in user.company_ids" instead of "child_of user.company_id". Would that be better / worth an effort as a PR? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#86>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2T6VR4Y6DKUT6AHFHFJQDQAHMPBANCNFSM4IFGLXXQ> .

[JordiBForgeFlow]

Btw Odoo is reviewing this repo for their multicompany refactoring. I assume they'll take it as a reference. El vie., 19 jul. 2019 17:34, Jordi Ballester Alomar < jordi.ballester@eficent.com> escribió:

…

That is precisely what Odoo is going to do for v13. We did not consider it, but I think that it's a good aproach. El vie., 19 jul. 2019 17:27, Tom ***@***.***> escribió: > @etobella <https://github.com/etobella> Yes, this is an option, although > when I create parent company "A" with childs "B" and "C", and I let users > work in "A", I actually dont want them to work in A but by default in B and > with the option of working in C. A is just a dummy company. However, for > example when I generate an invoice from a sale order, it will try to place > the booking in the journal of company "A", since it's the one selected - > all of those things would need to be overridden. > > Proposal: modifying all multicompany rules to be "in user.company_ids" > instead of "child_of user.company_id". Would that be better / worth an > effort as a PR? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#86>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AB2T6VR4Y6DKUT6AHFHFJQDQAHMPBANCNFSM4IFGLXXQ> > . >

[etobella]

I think that for 10, 11 and 12, our approach is the best approach because the change would be extreamly hard for javascript, rules and code

[thomaspaulb]

@etobella Modifying the rules will be difficult yes, but which Javascript problems do you foresee?