Using Hooks to make GNUmed do what you want

At various points in the workflow (such as directly after activating a patient) GNUmed can invoke a script to allow you to customize what is happening. This is both powerful and possibly dangerous: You can make GNUmed do nearly anything you want - but an attacker might also find a hole to exploit that for evil deeds. GNUmed has, however, taken a few precautions to try to thwart the average script kiddy or wannabe E7EET haxxor.

The documentation which comes with your package holds an example script hook_script_example.py which contains a lot of examples for some known hooks.

You can always learn the exact hooks your version of GNUmed supports by starting GNUmed with --debug (or check the [x] enable debugging field in the login dialog) and then looking at the log file.

The hook script

The script ~/.gnumed/scripts/hook_script.py is called for all hooks so there is a single script per user for hook actions.

This script file must meet the following conditions:

• must be owned by the user running GNUmed
• must have permission bits set to 100600 (- rw- --- ---)
• must have a module level Python function run_script(hook=None)

GNUmed will then import that file and execute the run_script() function at various times. The single argument passed into this function is named hook. It will hold the actual hook name the script was called from. This way appropriate action can be taken depending on which hook the script is called from. It can then do pretty much anything Python can do within the GNUmed framework - including finding out which user it is running as and which workplace it was called from.

Note that some hooks may be callled before or after the wxPython GUI is available.

Known hooks

• see the list of hooks in the latest source code

Note that some hooks may not yet be available in the currently released version.