Re: [Gnumed-devel] gnumed going into production

[Karsten Hilbert]

On Thu, Jan 22, 2009 at 08:15:39AM +0100, Hilbert, Sebastian wrote:

> > On Wed, Jan 21, 2009 at 12:06:50PM +0100, Hilbert, Sebastian wrote:
> > > a) get rid of demo data
> >
> > Why would this be of such big importance ? For nearly all
> > use cases it may suffice to simply "delete" those patients.
> >
> As far as I know there is no complete delete unless done via sql.
That is correct. The reasoning being that the perceived need
for that comes from a misunderstanding of the requirement to
NOT delete patient data. In some jurisdictions this is even
mandated by law. However, note that the desire to merge
duplicates also brings about the perceived need for
deletion. In that case no real delete is actually wanted,
rather a move of data - which is why we now support that.

> For some 
> users it might be sufficient to inactivate the patient but why would we want 
> to tell a potential admin/user to remove a film character.
Because they might want to deactivate the test patients when
going live ?

> If anything goes wrong in this process
Like what ? Well, OK, bugs can always happen.

> then there might be a backdoor left open in production.
A backdoor because of data in the database ? Because there
is yet another patient in a database of many patients ? If
you are referring to (test) accounts staying connectable
because of a bug in disabling existing accounts -- well,
we'd like to know about this bug sooner rather than later
because it would apply to "real" accounts just as much. And
we'd learn of it quickly if the admin was to disable a test
account and then perform the obvious double-check of trying
to re-connect with that now-expected-to-be-disabled test
account.

> > > b) please factor out the bootstrap of demo data
> >
> > Uhm, like, just the way it is now ?
> >
> As far as I know even in interactve mode I have not been asked explicetly for 
> the demo data.
You have, when bootstrapping v2. But the granularity could
be improved. Which is why it is configurable in the first
place by including or not including certain scripts. That's
mainly the job of package maintainers. The GNUmed project
strives to provide one database which works.

Surely I'll be happy to apply patches which improve things
all around.

> It was bootstrapped very early when I answered yes to a bunch 
> of other thing to bootstrap.
Yes, for gnumed_v2.

> If this is wrong please lay out how to disable bootstraping the demo data.
Check the .conf files. Remove those scripts from the list of
scripts which contain demo data. If a script contains both
needed and optional demo data - yell out, I'll split that
script as needed. Or send the split my way for inclusion.

> Is there a way to bootstrap any-doc or the like only which can then be 
> inactivated ?
Sure, comment out the corresponding sql scripts.

> If not I might have to setup a Wiki page and tell people to get 
> rid of test-nurse and the likes. 
They should be able to delete those accounts from the user
management dialog. This will only work if those accounts do
not sign responsible for any clinical data in the database
yet - but by default they aren't expected to.

> > A script can be written to add a GNUmed user from the
> > command line, though.
> 
> This would be nice.
I'd be happy to include it were one to appear in my inbox.

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