Re: [Gnumed-bugs] Allergies plugin breaks Workplace

[Jim Busser]

On 12-Jul-09, at 10:30 AM, Karsten Hilbert wrote:

> On Sat, Jul 11, 2009 at 07:17:54PM -0700, Jim Busser wrote:
>
> > > Hi, I added to my workplace list the Allergies plugin
>
> ...The tarballs creation
> script explicitely removes it. How did you manage to select
> it for the workplace ?

I selected it from inside the GNUmed > Preferences > ... > Workplaces  
menu, after (within the list of available Workplaces) I selected  
"GNUmed default", edited it, and added Allergies plugin which was  
listed there, as was a ConfigReg plugin and a Referrals plugin and so  
on.

Therefore the tarballs script either wasn't run, or did not do what  
it was expected to do? Or is there some way for plugins to get into  
the database, either via bootstrapping or via import from an earlier  
version database, when upgrading?

Did you wish me to email you any file listing from any particular  
directory within my untarred 0.5.rc3 tarball?

> > > The problem now
> > > is that with this coded in the database, it requires a workaround to
> > > fix (login using other workplace as manageable thtough a config  
> > > file,
> > > and then deselect in the GNUmed default workplace).
>
> Well, errors we *can* do something about are handled - such
> plugins will simply not load. Errors we cannot do anything
> about (because they happen below the Python layer) we cannot
> do anything about.
>
> > Actually I seem trapped *out* of my v11 database, since despite  
> > that I
> > logged in (using my client 0.4.6) to v10, and noted several of the
> > workplace names, and tried them each in
> >
> >         gnumed-from-cvs.conf
> >
> > called from
> >
> >         gnumed-from-cvs.sh --conf-file=gnumed-from-cvs.conf
> >
> > but even despite that I tried under [workplace]
> >
> >         name = Librarian Release (0.2)
> >
> > I could not get past the segmentation fault. Ideas?
>
> That seems to prove that the allergies plugin doesn't even
> specifically provoke the fault. It's nothing GNUmed can do
> anything about. The underlying libraries are broken
> somewhere.

So is the above implying that the broken libraries are unlikely to  
have anything to do with my selection of an unavailable or broken  
plugin?

Diagnosable?

Fixable by any uninstalling and reinstalling of any python packages?  
I am sensing there may be a job for apt-get here?

> > Do we wish / need "GNUmed default" to be non-modifiable?
>
> We wish, and we recommend against using it in production,
> perhaps needing more prominence.

Can I suggest we remove all of the existing Workplaces that have no  
current meaning except nostalgic or sentimental but will have no  
meaning to regular users? We can keep documented in the wiki, for  
example, what was available with Librarian Release (0.2). I think  
part of the problem is that users see so many pre-loaded workplaces  
that these are confusing. Also, it is customary for users to expect  
to need to change defaults, and therefore not unusual for them to  
select "GNUmed default", for the reason that they desire to *change*  
their default. The purpose of these other workplaces would be a  
mystery to most users who would more likely leave *those* alone than  
leave "GNUmed default" alone.

I suggest we ship GNUmed with only two workplaces, pre-defined to  
have the same plugins:

        GNUmed backup
or
        GNUmed reserved

and
        Local default
or
        Database default

so that in the absence of any other defined workplace, it would  
normally be the local/database default that would load, and only in  
the event of some other issue (or with knowledgeable user over-ride,  
to call GNUmed backup / reserved) would GNUmed backup / reserved get  
utilized.