Mission leg change events
When key changes are made to a mission leg, AFIDS tracks these changes so that users can review a history of these changes in the event. This can be used to trace operator error, or follow and audit trail of changes to see what happened to a mission leg.
- When a mission leg is updated with a new pilot: 2, "Pilot added to mission leg based on pilot request"
- When a pilot is removed from a mission leg: 2, "Pilot removed from mission leg"
- When a notification is sent to the mission coordination directory: 1, "Notification sent to mission coordination director"
- 2, "Pilot acknowledgements sent"
- 2, "Pilot request acknowledgements sent"
- 2, "Pilot requests processed"
- When a pilot request is processed: 2, "Pilot added to mission leg based on pilot request"
- When a mission itinerary form is sent: 3, "Mission form sent to Joseph Howley by email to firstname.lastname@example.org"
Mission leg change record
Event date. 'change_date' field.
Canceled. Was the mission leg canceled during this event? If so, the cancel reason is captured in the cancelled field.
Pilot ID. If the change involved pilot_id`,
If the cancel reason is changed, the new cancel reason is captured in the 'cancelled_to' field.
New pilot ID. If the change involves adding a pilot to the mission leg record, or changing a pilot, the id (pilot.id) of the new pilot is captured in the pilot_id_new field.
Person ID of the person who made the change. `mission_leg_change`.`change_by`,
Event type ID. `mission_leg_change`.`event_type_id`,
Description of the event. `mission_leg_change`.`event_desc`,
Person ID of the person who made the change. `mission_leg_change`.`person_id`
Viewing mission leg changes
Mission leg changes can be viewed from the mission leg view. There is a button on the mission leg view screen which displays a list of the change events for that mission leg, sorted by the date of the event.
When are mission leg changes recorded
When a mission leg record is modified
- A pilot is added or removed or changed
- The cancel field is changed, from null to not null, from not null to null, or from one cancel reason to another
- When a pilot request is processed
- When a mission itinerary is sent
These changes are handled by:
1. A database trigger on the mission_leg table:
delimiter | CREATE TRIGGER mission_leg_change BEFORE UPDATE ON mission_leg FOR EACH ROW BEGIN INSERT INTO mission_leg_change (id, leg_id, change_date, cancelled, cancelled_to, pilot_id, pilot_id_new, event_type_id) VALUES (id, NEW.id, now(), OLD.cancelled, NEW.cancelled, OLD.pilot_id, NEW.pilot_id, 2); END; | delimiter ;
2. The controller for the mission_leg table
3. The function that sends the mission itinerary forms