pest management & emu notifications deborah hill & mark bradley
TRANSCRIPT
Pest Management &EMu Notifications
Deborah Hill & Mark Bradley
Introduction
• Business need• EMu Procedures & Documentation• Notifications• Problems• Results• The Future - What next?
Business Need
• With a new Quarantine Suite the NGA has stepped up pest-checking procedures
• Need for the system to identify tasks to be done and track tasks completed, including results.
• All this data needs to be discoverable and reportable
EMu Procedures & Documentation
EMu Procedures & Documentation
• 1. How to request a pest check using TASKS• 2. Sample notification• 3. How to complete a pest check using TASKS• 4. How to update pest check status• 5. Pest checks, tasks, holders and parent-child
records• 6. How to check for pending notifications
Notifications
• What Mark will discuss:– What are EMu Notifications?– How do Notifications work?– Shortcomings of default setup– Customising notifications & testing results
Notifications – What are they?
• EMu Notifications are simple system generated reports that inform users when something requires their attention.
• They are included in many EMu modules - notably the Loans, Events, Insurance and Movements modules, and any module with a Tasks tab
Notifications – What are they?
• Examples include:– Loan commencement and completion dates– Event commence/complete– Venue commence/complete– Insurance: Cover notification– Conservation treatment commence/complete and
next treatment due.
Notifications – What are they?
• Specifically we are interested in the Tasks notifications.
• Task notifications can be run from any module that has a Tasks tab:– We use: Catalogue, Accession Lots, Events, Loans,
Conservation, Movements (internal and external)– Not yet used: Insurance, Narratives, Rights,
Groups
Notifications – how do they work?
• EMu automatically generates two types of notification reports:– an email message sent to specified users– an html (web) document
• Both are based on the same data and are generated simultaneously.
Notifications – how do they work?
• A script called “emunotify” is included in the off-the-shelf EMu package
• Our Crontab (system process scheduler) has been created to trigger emunotify at 12:30am Monday through Friday.
• At this time both the email and html notifications are generated.
Notifications – how do they work?
• The script checks for all records that satisfy the criteria:– Notify Date = today’s date– Notify field contains at least one user’s party
record
• Then generates the nofications and actions them.
Notifications – how do they work?
• The email message is sent to users in the Notify field.
• The email address used is from the Address tab in the Party record.
• A sample email notification
Notifications – how do they work?
• The html document is created and left in a pigeon hole for later viewing. This pigeon hole is determined by the EMu User ID, as per the Party record
• To view this, a user goes to Admin Tasks module and chooses “View My Notifications”
Notifications – how do they work?
• Can also view notifications for another user, by running the “View Another User’s Notifications” task.
• Access to this task can be switched on/off in the Registry.
Notifications – Shortcomings
• Default format very limited:– one style for Task Notifications across all the
modules.– The default just shows Commenced/Completed
Date, IRN, Task Description, People Assigned to Task, and Notification Date.
Notifications – Shortcomings
• Too simplistic• Our users want more information:– Summary Data for the record– clarity on which IRN we referred to (as some NGA
users insist on using “IRN” to mean “Catalogue record”)
Notifications – Solution
• Solution: Customise the Notification reports.• This was not easy. EMu Help has this feature
buried deep in the help file.
Notifications – Customising
• How are these reports built?• Rather than just one all-encompassing
notification report, each notification is made up of component parts
• These parts and how they are put together are determined by a script (written in PERL), named notify.pl
Notifications – Customising
• In our case, notify.pl file is found here: /home/emu/nga/etc/notify/ and /home/emu/ngatest/etc/notify/
• For other orgs substitute your environment for nga/ngatest
Notifications – Customising
• notify.pl looks like this
Notifications – Customising
• First Step – change the notify.pl definition to include more fields
• Here’s our current file
Notifications – Customising
• Second step – modify the Task.htm file
Notifications – Customising
• Noticed all tasks across all modules drew on the same notification file, task.htm. This means they all look the same.
• To get around this problem, made copy of the task.htm file for each relevant module (e.g. cattaskcomm.htm for Catalogue Task Commence)
Notifications – Customising
• Added in required extra fields, and also expanded field headings: “Catalogue Module IRN” instead of “IRN”.
• Example• Also required I edit the notify.pl to point at
the new htm file.• Example
Notifications – Customising
• Repeated this for each module’s Task Commence notifications, then for each module’s Task Complete notifications.
Notifications – Testing
• The biggest hassle – having to wait until the overnight Crontabs run to see the results.
• Solution: you can manually run emunotify from a terminal session (back end)
• Strongly advise you do this from the test environment, and not live or ALL the day’s notifications will be re-sent.
Notifications – Testing
• To see which environment you are in, type “client” at the command line
• To change environment type “client emutest” or whatever your environment is named. In our case the command is “client ngatest”.
Notifications – Testing
• Check logfiles to see if there are any errors, usually you can tell as expected email doesn’t arrive.
• Logs are found here:– /home/emu/ngatest/logs/notify/
Problems
• Party records – must have EMu User ID and email address entered correctly
• Code errors – one mistake can ruin the whole notification run!
• Version control – work in test, copy across to prod.
Results
• Here’s a sample of our email notification after the customisation
• And here’s a sample of checking mark-emu’s pending notifications via the admin task.
Results
• Less confident emu users now exploring modules they previously avoided
• Good level of commitment to new process, users are excited to see this level of automation happening.
• Cuts down on email communications• Approval from senior management
Future – so what now?
• Accurate reporting on pest management – to be actioned.
• Further refining the reports, better layout, include more detail.
• A stepping stone towards a workflow management system within EMu?
Thanks!
• If anyone else is interested in exploring these aspects of EMu we are more than happy to share our knowledge. So get in touch!
• Deborah Hill – 6240 6568– [email protected]
• Mark Bradley – 6240 6539– [email protected]