Having worked on a mostly generic app these days, I can tell you my
approach, which could be feasible or not for you.
My generic app builds the user-interface at runtime, and also builds the
data-modules at runtime.
I have a small LDAP (a hierarchic user-authentification server), where
my
app provides the user-credentials and gets the interbase username and
password together with a list of roles in return. The user can then pick
the role and connect to the server. He will never see his interbase
username password at all.
Also, there is a small administration-application which uses the same
LDAP to account forthe roles, and automatically create the
grant-statements in the database and adding booleans for reading,
updating, inserting and deleting into the ldap for the roles. So, you
never write a grant-statement for the app at all, but use the app and a
sort of graphical UI to grant rights to roles, and users to roles.
When the app has to build a new data-module, it simply goes to the LDAP,
reads the bools for the grants for this role, and applies the
prevent_xxx
properties properly _before_ opening the datasets.
Instead of using LDAP you can store own tables in your database, where
you
store the grants in a feasible way for every table and every role and
read
them on the fly before opening your datasets. If you create a
base-datamodule with a nice loop in the on-create-handler, and inherit
all
your other datamodules from this one, you should be pretty fine. You can
in
fact even parse the sql-statement, or use the tag-property of your
queries
for something useful to find out the table of the query on the fly.
This should add only a little bit of overhead to your app, and
form-loading
time should not increase that much.

Also, this way the buttons in your toolbars for inserting, deleting and
editing will be properly grayed out when a function is not enabled. Apps
with always enabled buttons are pretty confusing to the users.

Hope it helps, Nick

P.S. If my explanation was too confusing or too brief (I am not good at
explaining) drop me a private mail, and I will write something
longer....

> -----Original Message-----
> From: Martijn Hoedeman
> Hi all,
>
> One small detail which I couldn't find either in IBO or in the

newsgroup-

> archive, is the handling of user-security.
>
> Say a certain user only has read-access(Or no access whatsoever) to a

IB-

> table while others have full access.
> What would be a good way to check & handle this on the client-side?
>
> One method would be to read the database yourself (RDB$USER_PRIVILEGES

I

> think it is) but then you would have to do this with almost every

screen

> and it just feels like a waste of resource.
>
> When I started I (wrongly) assumed that IBO would check the current

rights

> in the database and adjust the controls accordingly. In case of the

user

> with only read-access the components would not switch to edit-mode.

But

> when I use a TIB_Query to access the table (And generate the
> Insert/Update/Delete SQL) it raises exceptions in case of too little
> rights.
>
> I just have the feeling that there is an easier way to handle/access

IB-

> rights on the client using IBO*
>
> Any help / Pointers welcome
> Cheers
> Martijn Hoedeman
>