Subject | Re[2]: [IBO] problem with permissions |
---|---|
Author | Ramil |
Post date | 2005-04-27T08:54:04Z |
Hello Helen,
At 27.04.2005 14:27, you wrote:
"RequestLive, ReadOnly and PreventEditing properties can't help in this case."
RequestLive is False
ReadOnly is True
PreventEditing is True
Any values combination all of them gives error, if assigned EditSQL and user
don't has permission.
What's the problem!
Anyway, let suppose what user has permission to delete records
but hasn't permission to edit them.
RequestLive I MUST set to True.
Why I get "no permission for update/write access to column ......"
error when I even don't dare to edit something.
Ramil
At 27.04.2005 14:27, you wrote:
> At 01:46 PM 27/04/2005 +0600, you wrote:I wrote:
>>Hi All,
>>
>>I have users with read only permission on some tables by PUBLIC user.
>>GRANT SELECT ON MYTABLE TO PUBLIC;
>>
>>And I have users with full access to table.
>>GRANT ALL ON MYTABLE TO OPERATORS;
>>(OPERATORS is a role)
>>
>>When read-only user execute statement for example "select MYTABLE_ID from
>>MYTABLE"
>>from any database tool it's ok! Whey allow him to select records from
>>the table and just disallow to edit or insert the table.
>>
>>With IBO I found little problem.
>>Wnen statement "select MYTABLE_ID from MYTABLE" assigned to IB_Query
>>and EditSQL property present with my custom update statement
>>i recieve "no permission for update/write access to column MYTABLE_ID"
>>on IB_Query.Open.
>>No one try to edit any records.
>>When I clear EditSQL before IB_Query.Open it's work fine.
>>RequestLive, ReadOnly and PreventEditing properties can't help in this
>>case.
>>
>>I understand I, can leave out what problem by clearing EditSQL property
>>in all my IB_Queries when user role is not OPERATORS.
>>But I think it isn't best way.
>>
>>Please consider this strange behavior.
> It is not strange behaviour at all. By making a dataset "live" you are
> telling the system that the logged-in user is to have the rights to write
> to the table. IBO correctly refuses to allow the non-privileged user to
> access the set as a live set.
> You can safely put your custom EditSQL, InsertSQL and DeleteSQL back. What
> you should do instead is to check the user privileges at connect time and
> set a flag indicating whether the role has the needed privileges. When the
> dataset is created, check this flag and set RequestLive accordingly. If
> RequestLive is False, the I/U/D buttons on the UpdateBar will be disabled
> automatically.
> Helen
"RequestLive, ReadOnly and PreventEditing properties can't help in this case."
RequestLive is False
ReadOnly is True
PreventEditing is True
Any values combination all of them gives error, if assigned EditSQL and user
don't has permission.
What's the problem!
Anyway, let suppose what user has permission to delete records
but hasn't permission to edit them.
RequestLive I MUST set to True.
Why I get "no permission for update/write access to column ......"
error when I even don't dare to edit something.
Ramil