> I am working on a simple user manager for IBO-Ibase/Firebird. I am
> looking for comments/suggestions.

Sounds like an excellent project.

> I. A user manager. It does all of the new user registration, grants,
> etc. from within the app. I haven't perfected it, but I will to get
> my app done. I can see two possibilities - either as an example app,
> or as a little component people can throw into their apps.

Do both :-) That is; Create the project as a component and then
create an application using that component. That achieves two things;
we get an ready to run user manager app AND we get a demo of how to
use the component in our own apps.

> I like to put a lot of effort into the exact permissions of 5
> different roles. Then, when you add a user, you pick one of those
> five roles for that user. It is clean, and works most all of the
> time.

This fits very well with how I implement in my own projects. I try to
keep the number of roles to a minimum - because they are of only
limited use anyway.

> Now, what about the cases where Mary W. needs to be able to have a
> little bit more access that her co-workers using the same role? Here
> are the possibilites:
> 1. Add extra permissions to her user name.
> 2. Create a special role for her, based on her previous role.
> 3. Bluntly upgrade her to a higher level and stick strictly to 5
> roles.

> I like 2 the best, because sooner or later somebody else is going to
> end up with Mary W.'s job.

I agree.

> III. The question is - Where to put the user admin tables and other
> info?

> 1. Each and every .gdb is its own little feifdom. This is obviously
> best in cases where there is just one .gdb at a company.

> 2. We have a user.gdb (analogous to the workgroup.mda in Access)
> that keeps track of users. Any other .gdb can join this little world
> and thus be subject to its command. This is best in cases where
> there might be many .gdb's, like my crazy company ;)

Can we have it both ways? Could you setup the component with a
special function to create the necessary tables etc - or perhaps just
distribute the necessary DDL script with the component.

Perhaps setup the component so that by default it expects each
database to have its own setup, but permit some sort of override to
use external GDB definitions.

I dont know how much this complicates what you want to do - if it gets
too complicated to offer both options then I suggest putting the
tables into each GDB, since that is the way that the (rather painful)
IB/SQL role based security is setup to operate.


If would be good if you can build some form of ISC4 synchronisation
capability. So that a maintenance operation can be run to keep the
specific GDB security and the ISC4 information in sync.


I have several other requirements for my own apps, but they all
require fiddling with the ISC4 database - something I am guessing you
would rather avoid.

--
Geoff Worboys
Telesis Computing