"create" permission in res.users dont work with other users, not admin

Hello,
I think this bug results of the changes made here :
https://bugs.launchpad.net/openobject-server/+bug/944813/+activity

If you don't use multicompanies you can simply solve it by changing back
[('company_ids','child_of',[user.company_id.id])]
to
[('company_id','child_of',[user.company_id.id])]
(or just removing the line) in Settings / Security / Record Rules for res.users.

If it can help, this problem occurs because inside orm.py, in the BaseModel create method, the new user is created, then the access rules are checked (so no problem to get the new user company_id), but the inserts into res_company_users_rel table are not made yet (so we don't get the new user in company_ids). This table is supposed to be filled later in the same method, when the var upd_todo is checked.

Hello Evelyn Martinez ,
we have checked issue at our end and have reproduced it , we have fixed in branch lp:~openerp-dev/openobject-server/trunk-bug-1021378-aja at revision no 4371.

Thanks for your contribution.

Hi,

the code of the create function has been modified a lot since then. Does it's possible that the bug came back?

I've got the bug with the nightly build sources of 6th of january 2013 on the version 7.0

Thanks!

Regards,
Houssine

Looks like the code in orm.py has not changed at all in this respect. The fix was just never merged with the official branch.

Hi Stefan,

Ok you're right! it has never been merged since august 2012!

Patch has been provided for months but we still have to investigate and report existing and fixed bug!

While we could spend this time on problems not yet solved!

hello openerp folks, this is a serious issue which needs to be fixed in 7.0.

Hello everybody;

Fixed or not
Merged or not
Multi-company or not
access rignts or not
.......

All that since July 2012 !!!

This is a very seriuos bug: Cause, users (other than admin) with all access rights can't add any other "user" nor "contact" (no Customer and no supplier).

Ok, maybe the trick described by Cedric Le Brouster work for 6.1, but it did not work for 7.0.

What should we do?
 Close this bug and OPEN an other one, or move to bug 1079028 or bug 1098219 (Yet Another Bug ).

Or, should all user logon with admin account, to get rid with this issue ?

Last thing: Why the field "share" (boolean) in the "res_users" table is not updated after assigning rights to a newly created user?
Even when updating the field manually, the ERROR is still here.

Thank you.
And best regards.

Hello;

What's wrong with: ~stefan-therp/ocb-server/trunk-bug-1021378-aja » Revision 4835 ?
Why it's not merged till today ?

Could someone give us a response.

Best regards.

Hi diassynthesis,

that particular branch is for the community backports projects, which has just been started. The process is not running optimally yet due to a lack of participants. I expect this to pick up sooner or later. Process wise, it should be merged by someone other than me. I will ask Camptocamp to merge it.

The original fix on the official branches has been ignored by the core developers up until now. I cannot do anything about that, but I have seen improvements in merge speed recently so it may help at this point if you comment on the associated merge proposal.

Hi Stefan;

Thank you for your response and for your advice.

But i can't understand why when the state of this bug is stated as "Fix Committed: Fixed, but not available until next release.." on https://bugs.launchpad.net/openobject-server since August 2012, and know since February 13 2013 the state is the same "Fix Committed: Fixed, but not available until next release.." on https://bugs.launchpad.net/ocb-server/7.0 , for a so important bug.

Should someone from OpenERP Team change the "importance" of this bug from "Medium" to "Critical" !!!

A precision; the error i get is slightly different: (Document type: Partner, Operation: create) and not Document type: res.users)
( see attached file)
But i think it's the same bug.

I get this error when trying to create a user after login with an other user (with full access rights) other than the admin.
I also get the same issue when trying to add a contact, customer or supplier.

I've tested this case with OpenERP 7.0 under Windows and Ubuntu, and get the same error.
Could you please confirm this case.

Thank you and best regards.

Hi diassynthesis,

I completely agree. That is why we started the backports project.

Cheers,
Stefan.

Hi To ALl of you,

Im supporting you all, as this is a verry critical issue, im using also arelease of january 2013 on the version 7.0.

and i steel have exactly the same issue, and the trick described by Cedric doest work for sure, and more than that,..Records rules are not working at all for other Users of Administrator access rights, All users other than Admin see his own User Record, .. even if i change the Record rule of res.users, or delete it...

So i can't use RH or Task affectation as expected, and then its verry bad, and hope really we can fix that asap.

Respectfully,

--
Youness

Hi Again,

Please i Confirme that the issue is also with Record Rules, even by deleting or modifing the Record rule mentioned by Mr. Cedrinc in TOP, no New created user as admin have rights to see other users..

Regards,
--
Youness

Hi Everybody;

Further Investigations

You can verify by yourself that this issue exist on the latest runbot releases for 7.0 and trunk but not for 6.0 and 6.1
http://trunk-4253.runbot.openerp.com
http://7-0-4260.runbot.openerp.com
.
.
.
http://6-1-4257.runbot.openerp.com

Also according to the content of openerp.log file :
<< 2013-02-20 18:36:39,023 8916 INFO gsctest werkzeug: 41.107.104.239 - - [20/Feb/2013 18:36:39] "POST /web/dataset/call_kw HTTP/1.1" 200 -
2013-02-20 18:36:49,286 8916 WARNING gsctest openerp.osv.orm: Access Denied by record rules for operation: create, uid: 12, model: res.partner
2013-02-20 18:36:49,286 8916 ERROR gsctest openerp.netsvc: Access Denied
The requested operation cannot be completed due to security restrictions. Please contact your system administrator.

(Document type: Partner, Operation: create)
Traceback (most recent call last):
  File "F:\Program Files (x86)\OpenERP 7.0alpha-20130107-000101\Server\server\.\openerp\netsvc.py", line 289, in dispatch_rpc
  File "F:\Program Files (x86)\OpenERP 7.0alpha-20130107-000101\Server\server\.\openerp\service\web_services.py", line 614, in dispatch
  File "F:\Program Files (x86)\OpenERP 7.0alpha-20130107-000101\Server\server\.\openerp\osv\osv.py", line 169, in execute_kw
  File "F:\Program Files (x86)\OpenERP 7.0alpha-20130107-000101\Server\server\.\openerp\osv\osv.py", line 125, in wrapper
except_osv: (u'Access Denied', u'The requested operation cannot be completed due to security restrictions. Please contact your system administrator.\n\n(Document type: Partner, Operation: create)')
2013-02-20 18:36:49,349 8916 INFO gsctest werkzeug: 41.107.104.239 - - [20/Feb/2013 18:36:49] "POST /web/dataset/call_kw HTTP/1.1" 200 - >>
We can see that this issue is related to access rights on the Model "res.partner" (also called Object in v6.0).
So what have changed since in Record Rules since v7.0 on res.partner ?

Searching in Record Rules for v6.0, v6.1, v7.0 and trunk, and comparing between the rules found,we will see:
1- there is one common rule: "res.partner company" on Partner Model with exactly the same rightsCRUD and Global
     and exactly the same definition - ['|','|',('company_id.child_ids','child_of',[user.company_id.id]),('company_id','child_of',[user.company_id.id]),('company_id','=',False)]

2- There is a second rule for v7.0 and trunk: "res_partner: read access on my partner" on the same Model (res.partner)
     with just "READ" Access right and defined for "Portal" and Anonymous" groups.

3- There is also another rule for v6.0 and 6.1: " Account Followup Statistics by Partner Rule" , but this is not important, cause it is on the object " Followup Statistics by Partner " and not the object "res.partner"

4- and the last rule: "Partner Bank company rule" whish also seems to be not important in our case cause it's related to res.partner.bank and not directly to res.partner

Conclusion:

The second rule (above) seems to be the cause of this issue.

Solution:
1- Put CRUD and Global rughts on this rule
2- Removing the access rights of users on "Portal" and "Anonymous" (Unchecking both)

Tested on runbot: the two solutions are not working

Tested on my development ...

Hi diassynthesis,

although the problem is related to the application of the record rules, your analysis is not correct. Did you try the proposed fix?

The record rules are applied too early in the creation process. In the case of users, there is a rule on company ids. However, at the moment that the record rules are applied, the company ids have not yet been set. The proposed fix moves the application of the record rules to the end of the creation process, when all fields have been set and the created resource does not invalidate the record rules anymore.

Hi Stefan;

Maybe you are right, but it seems to me that the combination of rules is the cause of this bug .. as stated hereafter in OpenERP
<< Interaction between rules
 Global rules (non group-specific) are restrictions, and cannot be bypassed. Group-local rules grant additional permissions, but are constrained within the bounds of global ones. The first group rules restrict further than global rules, but any additional group rule will add more permissions
Detailed algorithm:
1. Global rules are combined together with a logical AND operator, and with the result of the following steps
2. Group-specific rules are combined together with a logical OR operator
3. If user belongs to several groups, the results from step 2 are combined with logical OR operator
Example: GLOBAL_RULE_1 AND GLOBAL_RULE_2 AND ( (GROUP_A_RULE_1 OR GROUP_A_RULE_2) OR (GROUP_B_RULE_1 OR GROUP_B_RULE_2) ) >>

Maybe i'm wrong.

And i'm telling to my self, why OpenERP Team was not worried about this bug till now ? (six months later)

Maybe because the team consider this as not a bug !!! but rather as a configuration error, or at least there is a contradiction between rules.

Those 2 rules (res.partner company and res_partner: read access on my partner) are applied to the same object.
What happens when one user is linked to those 2 rules by his membership to some groups at the same time or if the rules are put Globaly ?

I repeat, maybe i'm wrong, but my wish is to end with this "Error or Bug".

I will patch orm.py as you adviced me and keep you informed, but i think we should continue our investigations.

Thank you Stefan and best regards.

Sorry did not read correctly. I think your user should not be in the portal group, which is a very restricted group indeed. I tested on the original example of res.users.

Hi Mr. Stefan & diassynthesis,

I Think your last analysis about Operantors is the issue...and combining those rules will generate the issue:

and i was thinking on that point, and i could fix it by doing does steps:

1- Removing "General" state of the res.partner Record Rule with condition <<<< ['|','|',('company_id.child_ids','child_of',[user.company_id.id]),('company_id','child_of',[user.company_id.id]),('company_id','=',False)] >>>> and to don't lose rights, i affecte it to ALL GROUPS .... /!\ IM DOING SO TO BYPASS THE "AND" Operator /!\

2- Same thing for the Only Record Rule of res.users.

3- Added 2 record rules with condition [(1,'=',1)] and affect all groups i need to give theme Rights ..( Project Managements...etc in my case..anyway)

But we hope it will be fixed with a Strong way, or maybe change the security lines if its not an issue of record rules..
Regards,
--
Youness

look at this, https://bugs.launchpad.net/openobject-addons/+bug/1073087

I described same thing, and same remarques about portal group from this Bug..

Regards,
--
Youness

Hi everybody;

If we begin to play with record rules (and ACL) this can lead us to impossible situations in an endless way (due to the interaction between modules and the inheritance between objects, and the very large number of cases we can choose ).
Before doing that, be sure to be able to revert any change to his original state (Just in case !!!).

Also, patching code has never been "a simple walk", cause it can have an unkown and hidden "side effects". If it must be done, it must be done carefully and surely, All we can do is to backport any change (as done by Stefan), or on it's own development platform.
(Why not creating it's own branch if necessary).

Let's return to our issue, and going deeper in our investigations (concerning the solution in my previous comment)
Known that there is no control over what an IT Admin needs to put as access rights for a given user on a given production platform in a given company (there is no 2 identical installations of OpenERP or any other ERP), how can we deal with such a situation (i mean what if a user need to be at the same time a Portal user or an Anonymous user, should the IT admin affect to him the corresponding rights ? If, yes we will face the same error and the same Bug ).

And here is my question: Why an OpenERP user (Employee-user) need to be a Portal user or an Anonymous user ?

Here is a BIG CONTRADICTION ! and a CONFLICT of access rights !!!

Please, keep on analysing this issue deeper.
We must close it asap.

Best regards.

Hi diassynthesis,

I understand your issue now better and I can see it is a real concern. But it is not related to this bug report. This bug report is about being able to create users, not partners and it is solved by the proposed solution. I suggest that you create a separate bug report and file your analysis there (please search existing bugs first, of course).

Hi everybody,

But Stefan, what was the solution ?? The fix released doesnt fix res.users access rules, or Creation of users for me...?? is that working for you ?? !!

excuse me , im little bit confused, the solution i just bypassed the issue, by using the tip i described in previous comment..

Any clarifications ??

Regards,

@BeatMind The fix was not released, you need to apply it yourself. I described how this fix works in comment #15.

yes the fix applied locally on the server solved the problem at least for
the version 7.0

2013/2/22 Stefan Rijnhart (Therp) <email address hidden>

> @BeatMind The fix was not released, you need to apply it yourself. I
> described how this fix works in comment #15.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1098219).
> https://bugs.launchpad.net/bugs/1021378
>
> Title:
> "create" permission in res.users dont work with other users, not admin
>
> Status in OpenERP Community Backports (Server):
> Fix Released
> Status in OpenERP Community Backports (Server) 7.0 series:
> Fix Released
> Status in OpenERP Server:
> Fix Committed
> Status in Therp Backports:
> Fix Released
> Status in Therp Backports server-6.1 series:
> Fix Released
>
> Bug description:
> When you create a new user and give permissions: Administration: "access
> rights". This group "access rights" has create permission to res.users
> table.
> Then login with this new user and try to create a new user, it dont
> work, the message is "Access Error Operation:Prohibited by the rules of
> access to or held in a document already removed (Operation: create,
> document type: res.users)"
> The result I expected was create a new user, by using a user different
> to admin, that has "access rights" permissions.
> The platform is ubuntu
> The Openerp Version is 6.1 rev. 4196
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ocb-server/+bug/1021378/+subscriptions
>

Oh @Stefan, that i was tring to tell you, This fix doesnt work for me, it doesnt fix the issue....

Im Confused!!

An other remarque about "res.partner" and "res.users", solving the issue will solve both of issues i think about, because now res.users inherits res.partner ..

Am i wrong ??

Regards,
--
Youness

@BeautMind if you want to be sure you can try to apply the fix in the following merge proposal:
https://code.launchpad.net/~openerp-dev/openobject-server/trunk-bug-1021378-aja/+merge/121995

Hi Yannick,

Thank you a lot, i don't know what heppens with me , but this is not working , if it works for you all, maybe im doing something wrong :o i don't how..

but thank you for help, im steel bypassing the issue by playing with record rules..

Regards,
--
Youness

Hi everybody;

Better investigations, the logical way:

1- An OpenERP user (as employee) can't be a Portal user, nor an Anonymous user and "Vice Versa".
      This mean that for the case of the error on 'res.partner' there is no Bug. The "Message error generated"can be considered as " a bad error handling", it can be replaced for examlpe by another message like " You are not autorized to perform this action", or for a better handling of such errors a message error can be raised when in configuration panel we try to check the boxes "Portal user" and/or "Anonymous user" for a regular user (Sale user, Purchase user ....) (a message like "WARNING: THIS USER CAN'T BE A PORTAL USER OR AN ANONYMOUS USER").

2- For the case of the error for the Model 'res.users' ("user can't add another user"): What if (in OpenERP) only admin user is able to add "another user" (maybe for a better level of security management )???
(Precision I'm not talking about adding an employee in HR, but about OpenERP system user which may also be an employee).

Thank you for you all and Best regards.

Hi diassynthesis,

Ya its extremly clear now, ive tested that million way, for res.partner, and then yes, if OpenERP try to make it like this, so we should push there a fix for that, to raise the message !!!! IF no one will do that, maybe i can propose a fix !

But im not sure its a good idea having create access for res.users to only admin, and if its about security, all record rules should do that by a fast configuration...and then it shoud give choice to admin, give "create" access to other users or not !!

Regards,
--
Youness

The fix has landed in 7.0 at revision 4894 rev-id: <email address hidden>
(it will be ported soon in trunk)

Thanks for reporting!

Hi
We are running openerp-7.0-20130307-002146 since a week or so. We are new to the product but IT company so we understand the issues. I'm afraid to say I'm a bit disapointed that this kind of serious bugs are not resolved fast and accurately. For now I can't contribute to a solution , but just stress the importance to solve it.
We encountered the problem as it is described above: The Admin could n't create a new user assigned to another new company. Stuck.

Have a great life

Hi Kenneth,

if you read the last post before you, you will see that this bugfix was actually released one week ago so you can simply upgrade OpenERP 7.0 to make it work.

Stefan.

If running a small 2 user, not Enterprise system, does an UPGRADE just entail reloading BZR or is there a specific Patch or Script that also needs to be run.

I loaded BZR about Jan 12 13.

thank you,
Landis

@Landis

As it is in python, you just need to upgrade the server branch to rev 4894 revision-id: <email address hidden> or later and restart openerp.

This fix was made on 2013-03-14 so if you didn't updated your branches you just need to run a bzr pull or bzr update on your branch.

Thank you Yannick. I will do that now. I need to read up on update/vs pull. I have a Turnkey Linux Server I need to learn how to set keypairs to it. Right now it just runs anonomysly and I think I can only one option... but will test now.

I have version of 2013-04-15 (Today) and don't work for me.

I found a solution for this. I not tested all permissions but for now, is working.

File: openerp/osv/expression.py
Line No: 1196

Overwrite: return query, params
For:

# ALCA - Modificado el 15/04/2013
        if query == 'FALSE':
            return 'TRUE', params
        else:
            return query, params

I don't know why, but if the leaf don't have value, and are operator 'in', this function return FALSE and make the STRING SQL with ' AND FALSE' and don't work.

The user admin work because it's hardcode. if superadmin all ok.

Hi Carlos,

please do not change the status of the bug in OCB addons. The fix that solves this particular problem is merged. A number of people discussed a distinct problem later on in this thread. Please file a separate issue for that problem.

Thanks,
Stefan.

Ok. Thanks