[Top][All Lists]
[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