ChemAxon 1c5962da67
25-04-2014 11:10:26
Question:
Project based restrictions don't seem to be working as I expected in the version I am working with (v6.2.0).
Scenario:
- Two users: demouser, demouser2
- demouser is a member of Project 1, full access. demouser2 is not a member of Project 1.
- demouser registers a compound under Project 1
- demouser2 can search and display the compound (did not expect this)
-
When attempting to change the LnbRef , demouser2 does receive a "system
error" about operations not permitted with existing roles.
When attempting to change the LnbRef , demouser2 does receive a "system
error" about operations not permitted with existing roles.
- demouser 2 receives a system error that "The function
GET_AUDIT_SUMMARY is not permitted with your exising roles" when
attempting to change the restriction level, however the restriction
level actually changes.
GET_AUDIT_SUMMARY is not permitted with your exising roles" when
attempting to change the restriction level, however the restriction
level actually changes.
I expected that demouser2 would not be able to see
or have search results displayed for the registered lot which was in an
inaccessible project.
or have search results displayed for the registered lot which was in an
inaccessible project.
Is this a known issue
that will be corrected before the release, or am I not understanding how
the project accessibility enforcement should work?
that will be corrected before the release, or am I not understanding how
the project accessibility enforcement should work?
Answer:
You are understanding well the fundamentals of the project
accessibility control, but we haven't discussed so far what are
the prerequisites for setting up the project based access control.
It has to be configured at the very beginning if you decide to use
it. There's a parameter in the parameters table of the database
called GlobalProjectAccessEnabled. By default it's value is set to
true, which means that there are no restrictions regardless of
your settings on the access control tab of the Administration
page. You have to set its value to false, and then run SQLDeploy
again, this way the acl_* tables of the schema would be initiated
properly. Unfortunately at the same time all your existing data
will be wiped out, that's why I wrote that ideally it has to be
done at the very beginning.
On the other hand the message that you got ("The function
GET_AUDIT_SUMMARY is not permitted with your exising roles" ) is
simply because the roles of that particular user are not set up
properly, it is not related to the project based accessibility.
accessibility control, but we haven't discussed so far what are
the prerequisites for setting up the project based access control.
It has to be configured at the very beginning if you decide to use
it. There's a parameter in the parameters table of the database
called GlobalProjectAccessEnabled. By default it's value is set to
true, which means that there are no restrictions regardless of
your settings on the access control tab of the Administration
page. You have to set its value to false, and then run SQLDeploy
again, this way the acl_* tables of the schema would be initiated
properly. Unfortunately at the same time all your existing data
will be wiped out, that's why I wrote that ideally it has to be
done at the very beginning.
On the other hand the message that you got ("The function
GET_AUDIT_SUMMARY is not permitted with your exising roles" ) is
simply because the roles of that particular user are not set up
properly, it is not related to the project based accessibility.