We wanted to share with you the results of our analysis held Monday January 14th about the recent set of bugs reported on the form take page, with a high impact event on Friday January 11th.
The event started at 8:00am with a report from one of our customers about problems with Internet Explorer causing the screen to go white and followed by a report about error messages displayed when clicking a radio group. We were able to diagnose what was happening, create fixes and deploy them by 12:30PM the same day.
Related to this we also experienced a serious bug just before this where drafts were not being saved in any browser. Due to the impact that these first two bugs had on one of our customers at a critical time, and because we had discovered several bugs in the same system location within a short period of time, we triggered a post mortem to look at what happened and what we can do better in the future.
Bug #1: There was a legacy bug with ratings that were configured with text as the value, but only if that text had a comma in it.
The Problem: There was one particular form question that had the same values configured for both the label and value for each form answer. This was to support required behaviour from the performance report, but was unexpected usage of the system. One of those values had a comma in it. If that value was selected, the comma caused an error that made the system behave as if a required field was missing.
Our Actions: When we analysed the situation we realised that having special characters in the values field was unsupported. We decided to handle the special characters directly to prevent the error from occurring and so that we could leave the existing form data intact.
Bug #2: In internet explorer, due to non-standard CSS behaviour, the whitespace of the footer could grow indefinitely while interacting with the form, causing the page to become purely white as if it was blank or loading.
The Problem: This was a purely technical issue where IE behaves completely differently from Chrome for a particular CSS attribute, but only for certain form fields in our context. This had been working without issue but due to a small code change, there was a specific form field type that caused the problem.
Our Actions: We implemented IE specific handling for what we were trying to do with this CSS attribute which prevented the problem from occurring.
Bug #3: The save draft button became unlinked from the form data, causing an empty data object to override the draft form answers that was supposed to be submitted or was already present in the database. This bug was occurring in any browser.
The Problem: This problem occurred Friday 4th when a code change unexpectedly introduced a problem where the draft answers were being sent to the back end completely empty. This was not observed at the time (as draft behaviour was not expected to be affected) and was fixed Tuesday 8th around 5pm.
Our Actions: We fixed the draft submission as soon as it was noticed but unfortunately any drafts submitted in that time frame were lost as they were never sent to the backend servers due to the nature of the bug.
We apologise again for any inconvenience that may have been caused to your organisation and welcome any feedback you may have have about this event or our response to the issues faced.
To provide us feedback please send an email to email@example.com or shoot through a support ticket inside the intelliHR platform!