- The app versions remain the same:
iOS: Native: 2.1.0, JS: 2.2.0
Android: Native: 2.1.0, JS: 2.2.0
Prevent observer app bookings 95 minutes before trip start:
As drivers are able to start a journey in their app 90 minutes prior to scheduled start, a restriction has been put in place so that observers can't book passengers onto trips if these are due to start within 95 minutes, as passenger changes wouldn't be visible to drivers.
If an observer tries to book a passenger onto a trip that is due to start within 95 minutes they will be shown an error for the affected date:
Not Boarded notification:
A not boarded notification would be sent to an observer where a passenger boarded at an earlier stop to that scheduled. This has been resolved, and observers won't be sent not boarded notifications where their passenger is already on board the vehicle.
Experiment with Wonde API:
Wonde integrates with the leading Management Information Systems (MIS), providing read and write access to school data. Experimentation has been undertaken to see how Kura can integrate with Wonde to allow passenger and observer data sync directly from MIS systems.
The initial load and update process is being tested to ensure that passenger and observer profiles are created successfully and any updates are accurate. Integration will be tested with an existing organisation, with a script written to allow existing profiles to be retained based on unique passenger ID and observer email address.
In the future the Kura website will be modified to allow an organisation to add their Wonde ID for this to be authenticated and approved, so that a link between Kura and Wonde can be established for passenger and observer information to maintained directly from the organisation's MIS.
Journey notification cache clear:
When a notification was sent from a journey screen (Trips->View Trip->View Journey->Send Notification), the message text entered wasn't cleared once the message was sent or if cancel was selected. Any message text entered will now be cleared where the message is sent or the request is cancelled.
Trip Map - Long and Lat:
When searching for a waypoint during route creation, if a lat or long was entered incorrectly into the map, for example, too many digits were entered such as a long of -0.74406 and a lat of 519.51084, a screen would show with a something went wrong error and the route information added to that point would be lost. The lat and long fields have now been changed so that it isn't possible to add a lat or long with too many characters, either manually or by pasting a value.
The following items were released during the last 2 weeks:
Booking export from WK40:
The booking exports had an unexpected date format, for example YYYY/10/Oct 16/2020 rather than 2020/10/16, and the trip date matched the action date. This has been resolved and the exports for week 40 onwards have been re-run so that the data format and trip dates are correct.
ActionID not populated in Quicksight:
Alarms weren't shown with an action ID in Quicksight. 'actionid' has now been populated so that the number of alarms can be counted; to identify the worst performing routes so that these can be optimised.
Quicksight event data from 14th October:
Events were missing from Quicksight from 14th October. All events have now been populated so that there is no event data missing in Quicksight.
The following items are in progress:
Ongoing - Logging improvements:
Logging of system errors has been improved to allow for effective identification and alerting of issues.
Ongoing - System restore from backup:
The process to back-up and restore Kura systems has been improved to allow for a quicker recovery in the event of a system failure. There are a couple of system areas where back-ups are being enabled.
Ongoing - Alarms prevented from closing:
There have been a number of alarms that show an error when attempting to action or close. This is caused by a sort key for journey, that occasionally creates duplicates and causes conflicts. The sort key uses event timestamp and has been extended to include nano-seconds, to avoid duplications that prevent alarm action or closure or the over-writing of journey information. Database transfer is complete on UAT. The next steps are to point the APIs to the new database and to transfer historical data. Once complete data will be removed from the old database.