Re: [Gnumed-devel] Re: Bootstrapping for production -- omitting test data

[Karsten Hilbert]

On Sat, Jul 25, 2009 at 02:12:48PM -0700, Jim Busser wrote:

> So I tried answering no (thinking it would skip the test account
> portion of the setup which is what I "really did not want") but that
> just aborted the process.

I can see how that's misleading.

> When I did go through the process I did notice that up to the
> bootstrap v4-v5 there appear to be no transfers of existing users
> but beginning v5-v6 these appear to be transferred (see below) and I
> wondered if that is relevant

They are transferred manually inside an SQL script. Only
later did I invent a generic method to transfer users which
lives in a function inside the database.

> 1) if a site would wish to install gnumed (without users) for
> production, and
> 
> 2) if it is also relevant to (and intended or unintended) that
> GNUmed must use two separate backups for dumping users and dumping
> patients/data.

GNUmed doesn't care but PostgreSQL mandates that split.

> As far as installing gnumed without users

This isn't possible.

> As far as production creation of users, would it be better that this
> be done via command line interface (psql)? Some kind of CREATE USER
> command that would need to include the gm-dbo password, the proposed
> user's account name, alias, password and privilege groups ?

No. That is what we invented gm.create_user() for - to have
a single point of truth.

> But then, if users must exist in the person table, must the creation
> of an account also create the person

No, because the account is an entity in itself. It is just a
database account. There is 4 aspects making up a GNUmed user:

- a database account
- a person in the database
- a staff record in the database
- an association between a person, a staff record
  and a database account

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346