Re: [Gnumed-bugs] Allergies plugin breaks Workplace

[Karsten Hilbert]

On Sun, Jul 12, 2009 at 09:52:21PM -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.

I downloaded the tarball and checked - it doesn't contain
those plugins. The list is taken from the local disk so it
must have found those plugins somewhere. If you happen to be
able to identify the relevant log (or can re-create this
state) the log will tell us where it eventually found the
plugins.

> 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?

The list isn't taken from the database. It is taken from the
installation - after all only those plugins locally
installed can be used.

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

client/wxpython/gui/ would be interesting.

>>> 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?

It wasn't implying that but, yes, that much can be suspected
as well. Those are likely separate issues.

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

You might want to run a systemwide search for the file
gmAllergiesPlugin.py and see what that turns up.

> 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.

How about this:

- clone "GNUmed default" to "GNUmed Demo"

        - we cannot simply rename because apparently people will
          be using "GNUmed default"

- add "GNUmed Fallback"

        - the provider inbox and report generator plugins only
        - to be used as a failsafe fallback

- keep "GNUmed default" for people to tinker with

- add a deprecation message about other workplaces
  and delete them in 0.6

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