Is there an obvious way to do this in python?

[Bryan Olson]

H J van Rooyen wrote:
[...]
 > This is broadly what I had in mind, yes - but sort of down to 
a transaction
 > level - this user does invoicing, this one enters cheques, 
this one does credit
 > notes, and their supervisor can do all three, and in a 
different department its
 > different because the jobs are different, but the invoicing 
GUI module is the
 > same for wherever its used...

Pretty much any business has to deal with those things. You are
right about the need for transactions and authorization, and
that you don't want to have to manually update all the clients
whenever your modify the applications. Everyone has those
problems, and consequently there's a large body of experience
and conventional best practice. The highly redundant advice
you've been getting is recommending that you to do those things
that way most successful modern systems do them.

No question what you describe calls for a DBMS. Further, this
sounds like a job for a "three tier" architecture, what Dennis
L. Bieber explained as [db-server] <-> [app-server] <-> [client].
In the old days a three-tier system called for a large
data-processing staff; today one guy can set up a simple one in
an afternoon.

In a three-tier system, either the database, the server
application can enforce authorization policy. In order for the
database to enforce authorization, the application creates one
database connection for each client user, and logs in as the
user. That works well for most accounting-type systems, where
all the users are known in advance. In systems such as web
shopping carts, the application typically has its own user ID,
and creates all database connections as itself. The app, not the
database, is then responsible for keeping users from reading and
altering each other's data.

Trying to enforce authorization at the client is generally a
mistake. The user has too much control over his local machine.
He is not limited to running just the code you provide.


Don't get too hung up on choice of DBMS, but stick with portable
standard SQL. I bet you'll find your potential customers want it
to run against the database they already have. The particular
tables your system needs will become part of their larger
schema.


--
--Bryan