[Gnumed-bugs] Bug deleting parts from Attach Documents

[Jim Busser]

Upon clicking the "delete parts" button, the part disappears  
immediately, and the user who did not notice can be confused by being  
presented immediately with a dialog that appears to be confirmatory,  
except it is not confirming the deletion of the part (which was  
already a done deed) but whether to delete the *source* file for the  
part that has been removed from the list.

I concede that technically it is not a bug, but it can be prone to  
human misinterpretation and therefore error and problems. Suggest:

1. existing users be asked whether they would object to the addition  
of confirmation to parts deletion. It is possible they will have  
gotten used to it and therefore object as not needing to confirm saves  
time if they often add parts by mistake, but IMHO it is not usual to  
do this. On the Mac, you hold down the Option key while selecting a  
menu item, or drag-and-dropping, or button-clicking, if you wish for  
example to force the emptying of Trash without confirmation, or  
otherwise knowledgeably modify a usual action. If they do not object,  
great, if they object, well... can it be further discussed? I am  
thinking we should probably be aiming to be consistent.

2. while it can benefit workflow to be able to delete redundant source  
files, the action should likely be applied to all parts, and might be  
better relocated into the Save subroutine. I would suggest -- to the  
right of [Save][Discard]) -- a checkbox that says

	"Permanently delete the source file(s) after a copy has been imported  
as Part(s)?"
        or
        "on Save, delete the source files for all parts".

In the attached screenshot I moved the "deletion" dialog to capture it  
in a small png. My proposal would be:

i. checkbox always defaults "off" upon opening the "Attach documents"  
plugin, yet holding in memory any value altered while this patient  
remains in focus (or at least while the plug-in remains in the  
foreground)

ii. at "Save", if unchecked, the option to delete source files is  
bypassed

iii. if checked, the user is presented with a confirmation dialog  
that, in its most simple form, asks:

	Permanently delete the source file(s) after a copy has been imported  
as Part(s)?

… while a more complex dialog could offer all of the source names, and  
could even allow individual tagging (checkboxing) for deletion or  
preservation, the source file names could be arranged to still be  
visible in the Parts area and referenced with

iv. suggest that for the confirmation dialog, change"No" "Yes" to  
"Cancel" "OK" as this pairing is IMO less prone to human error   
"Cancel" is more easily (mentally) associated with erring on the side  
of caution, whereas this is not always true (or at least requires more  
mental attention) with "No".

v. suggest that the source deletion (even if requested) not proceed  
until it is possible for the GNUmed client to receive back (from  
postgres) confirmation of the successful "save" of the newly-attached  
document. If it was unsuccessful, the offer to delete the source  
should not even proceed and, instead, the user should be informed.  
Maybe they should try again? Can the parts area continue to hold its  
list of parts? Or would it be better (in case one was the source of an  
error, maybe a corrupt source) what way of handling a failed save  
would you suggest?