gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] re vaccination batch no


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] re vaccination batch no
Date: Thu, 29 Dec 2005 23:41:12 +0100
User-agent: Mutt/1.5.11

On Wed, Dec 28, 2005 at 05:27:53AM +0800, Syan Tan wrote:

> what are the unix rights for your setup ?
Debian standard, no changes.

> is pg_hba.conf only writable by root,
yes

> and do you bootstrap gnumed as postgres ?
no, as my standard non-root login

> I remember a prompt existed in boostrap script once that
> asked you to be root in order to run bootstrap.
We have a warning that it might lead to problems to not be
able to become root inside the script. Given proper setup
there aren't any, however.

> This might be in accordance with the need to
> put gnumed into python site-packages as well,
No, any client installer would be run by a user with
appropriate powers. To install system-wide packages into a
system one needs system powers. To install a database into a
database server one needs appopriate database powers.

> postgresql 8.0 on unix makes it possible to have groups of databases with
> independent conf files , so it would be possible to have a gnumed ony 
> "cluster"
> , and allow your 
> installation to install a intranet only pg_hba.conf,  and get it to prompt for
> the ip mask that applies to
> intranet ( assuming a single ip mask for a small intranet for a practice).
Sure, why not. If a company decides to sell a setup like that, fine.

> I had nothing to do, and wanted a working client in order to try out some au
> development, so I put the
> changes in the cvs , which match your schema changes.
Thanks.

> I also fixed the "no
> repaint unless resize top frame" 
> which occurs on my gnome setup, by using a slightly hacky workaround where the
> user is required to
> check the identity of the "next patient" selected, as the gui switches to the
> demographic tab; 
As I said, pending a better solution I am fine with this.

The workaround might be slightly simplified but restricting
oneself to simply auto-changing tabs after patient selection
without further magic which - upon re-changing tabs - will
(should ?) make the client repaint itself.

> One of the most common errors when very busy , I find, is to start to write
> notes and print scripts on the previous
> patient.
Yes, it does happen.

> Automatic timeout logout might be another feature you could add, as
> this can be a problem if one shares "rooms"
> and does a session , and the previous doc hasn't logged out (  a minor 
> problem,
> and a brief annoyance, but it happens
>  at 2 practices  ).
Feel free to go ahead. Make it configurable, please,
however, as some people will be *very* annoyed by that
(think single-doc - or lazy - practices).

Configuration should be site-wide, regardless of user or
workplace which prompts me to realize that we need

 cCfgSQL.get_sitewide_option()

in addition to

 .get_by_user()
 .get_by_workplace()

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




reply via email to

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