Subject Re[2]: [IBO] problem with permissions
Author Helen Borrie
At 02:54 PM 27/04/2005 +0600, you wrote:

>I wrote:

RequestLive needs to be set to False. Now that I come to think of the
logic behind RequestLive, it's not considered at all when you have custom
XXXSQL. That means you DO have to apply the XXXSQL properties
conditionally, so as to eliminate the chance of their presence overriding
RequestLive false.

Another alternative is not to make the dataset updatable at all, but to
implement independent methods (use TIB_DSQL components) for the write
operations and make them available conditionally in your code.

>ReadOnly and PreventEditing properties can't help in this case."

No, because they are client-side properties only.

>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!

Just get your designing hat on and work out the simplest formula to cater
for the conditions that you want to cover.

>Anyway, let suppose what user has permission to delete records
>but hasn't permission to edit them.
>RequestLive I MUST set to True.

No. In that case, you would need to separate the Delete operation from the
dataset, by placing the DML for the Delete operation in its own DSQL object
and making it an independent method.

>Why I get "no permission for update/write access to column ......"
>error when I even don't dare to edit something.

Because you have created a conflict situation between the user permissions
and the dataset. The more complicated your conditions, the more things you
will have to take care of. There is no magic bullet here. In short, if you
have to manage conditional permissions in your applications, you have write
conditional code to handle them.

If you have a fairly simple situation where one role can do anything, while
another role can only read, then consider conditionally setting the
transaction read-only.

Under some more complex conditions, you could make your own "magic bullet",
by intercepting the permissions exceptions and handling them, by simply
cancelling the operation and delivering a user-friendly message to the
status bar.