Re: Feedback Re: [Gnumed-devel] GNUmed Release 0.6.rc1

[Karsten Hilbert]

On Sun, Nov 29, 2009 at 05:01:09PM -0800, Jim Busser wrote:

re deletion / notifying non-handling of messages:

> Before answering the above, I would argue it useful to
> have more ways to easily delete than only the control-click.

Right-click, but yes.

> IMO customary for a GUI to supply buttons for the most
> frequent actions. Shall we supply in the Inbox a "Delete
> message" button? 

Eventually, yes.

> When allowing the user to delete a message that pertains
> to unreviewed documents or labs, do we wish to warn the user
> that this only deletes the notification

It does not delete those (as you noticed) which will be
readily visible if bewildering.

I added a column .is_virtual to the dem.v_message_inbox view
such that we can safely detect such messages. Such virtual
messages are better thought of as notifiers.

Attempting to delete on will result in a beeped

        You must deal with the reason for this message to remove it from your 
inbox.

in the status line.

> (but that the related documents or results remain unreviewed)?

Due to the above behaviour this is not necessary.


> I am
> wondering if it is better to not allow this, in other words
> that it is only after (automagically upon) their being
> reviewed that these would disappear and attempts to delete
> them prematurely would issue a warning?

This has, of course, always been what GNUmed did.

> This might answer whether it is a bug that despite trying
> to delete "clinical/review results" / "unreviewed results
> for patient Kirk" the message does not in fact get deleted?

Yes. It is not. Think of it as a notifier rather than
message. IMO notifiers would exist as long as the condition
they notify on exists.

> Do we wish to make it possible in the inbox to reassign
> the message to some other clinician? Wishlist?

Yes, eventually.

> Or would it
> automagically happen already if unreviewed results would be
> reassigned?

Surely does.

> Double-clicking would ideally bring the user to useful action. In absence of 
> any other defined workflow for a message category and type, I would suggest 
> we keep the popup, and that it say:

>       "No double-click action defined for this message category and type."

Ah, OK. So it now sayeth this:

        No double-click action pre-programmed into
        GNUmed for message category and type:

         [%s]

I avoided "defined" as this might make the user think they
can (easily) define one themselves (they can but they'd have
to hack the source code).

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