| Subject | Re[2]: [IBO] problem with permissions |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-04-27T09:21:02Z |
At 02:54 PM 27/04/2005 +0600, you wrote:
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.
for the conditions that you want to cover.
dataset, by placing the DML for the Delete operation in its own DSQL object
and making it an independent method.
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.
Helen
>I wrote:RequestLive needs to be set to False. Now that I come to think of the
>"RequestLive,
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 FalseJust get your designing hat on and work out the simplest formula to cater
>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!
for the conditions that you want to cover.
>Anyway, let suppose what user has permission to delete recordsNo. In that case, you would need to separate the Delete operation from the
>but hasn't permission to edit them.
>RequestLive I MUST set to True.
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 ......"Because you have created a conflict situation between the user permissions
>error when I even don't dare to edit something.
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.
Helen