[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: Bootstrapping for production -- user accounts

From: Jim Busser
Subject: [Gnumed-devel] Re: Bootstrapping for production -- user accounts
Date: Sat, 25 Jul 2009 15:51:37 -0700

On 25-Jul-09, at 3:19 PM, Jim Busser wrote:

How about:

- let us clone gmPublicAccounts.sql calling it gmProductionAccounts.sql

Better yet, the methods used in test_data (for example Julian Bashir)
insert into dem.staff

seem more appropriate than the method in gmPublicAccounts.sql which only creates
select gm_create_user('any-doc', 'any-doc')

so maybe make provision in bootstrap-latest.conf for


and in




and through *that* (at the same time as removing dob, which is no longer needed, and COB, which is not needed) create a real user who would be appropriate to be then able to create other users within the GNUmed GUI.

By so-adapting the bootstrap,


would not even have to be commented out in bootstrap-latest.conf, since it could be allowed to run with the data file populated by pseudo-real person data. That way, the individual who would be running the production bootstrap would only need to
1) disable demo user account and demo patient creation and
2) alter values in the one sql file.

But as we saw from my last few emails, disabling the demo user accounts and demo patients and data takes a lot of steps prone to human error:

- bootstrap-test_data.conf (in bootstrap-latest.conf)
- several Data and Accounts .sql lines yet to be confirmed in bootstrap-monolithic-core

Can these all be pulled into some other conf file?

While I think I am close to being able to achieve my own uncontaminated production system just by hacking all these bootstrap files, I think we have here a good opportunity to reduce the finickiness of implementation for everybody who would follow me?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]