8/07/19 Release

User role name has been added to the Download Contact Info report

A new column named “Role” has been added to the end of the Download Contact Info report
The column displays the name of the reported user’s role (Prospect, Member, Trainer, Salesperson, etc.)

Agreement salesperson not being reflected as expected in reporting and KPIs

Membership units with corresponding appointment events were not being counted as closes, when we would expect that the membership unit close would be associated with the appointment event owner.
We migrated the data and confirmed that the results for reports and KPIs match what is expected.

Data discrepancies seen for overdue follow-ups in "Follow-up Scorecard" report

There was a discrepancy reported between the data in the Follow-ups Scorecard report and the Follow-Ups Overdue widget in the web app. The Follow-Up Scorecard report was only supposed to show follow-ups for prospects for today, but it was erroneously including follow-ups for prospects for both today and tomorrow.
We updated the follow-up end date in the code, so that only prospects for today are included.

Error when leaving a lead note on an certain member account

A generic and unhelpful error message was being returned when trying to save a lead note for certain members.
We found that the note entered by the customer contained the word “error” in the note body. The front-end code that fetches notes from the back end upon saving was looking generally for the word “error” in the data from the back end in order to find errors that may have occurred during the save process. Therefore, when the word “error” was found in the body of the note, the front-end recognized it as an error.
To avoid this situation in the future, we changed the front-end code to only flag the word “error” when it is the first word in the response from the back end. Since any actual notes are html, they will always have characters preceding the note body, so our fix allows us to only throw an error if the first word in the data is “Error”, which would only be sent in the event of a real error.

Employee Active Clients report does not include all eligible clients

It was reported that employees were missing from the Employee Active Clients report.
We determined that the code that generates the report was matching users on first and last name and eliminating duplicates from the report.
We made an update so that now the matching is done on first name, last name, and TFO User ID, so that only users with a duplicate TFO User ID will be omitted from the report.

Computer’s timezone affects displayed billing date when selling a new agreement

It was observed that agreements in the draft state were showing a billing date based on the logged-in user’s timezone, rather than that of the computer/browser. Depending on the timezone, that could mean that the billing date displayed as one calendar day prior to the selected start date. Once the agreement was sold, the billing date became correct (it matched the start date).
This situation was confusing for users, so we made a change so that the billing date respects the computer/browser’s timezone while an agreement is in the draft state.

“Canceled” was spelled differently in different parts of the web app

When trying to edit a canceled agreement, the modal alerting the user to the fact that a canceled agreement is not editable was spelling the word with one “l” (“canceled”), while the badge next to the agreement name was spelling it with two “l”s (“cancelled”).
We made an update so that it is spelled “canceled” in both places.

Fitness graphs needed update

Users reported that fitness graph data was not populating when they selected a measurement in the web app.
It was discovered that the plugin we use for fitness graphs (ZingChart) would only load Flash content with the user’s permission, but users were not being prompted to allow Flash to run.
We made a change so that ZingChart uses Canvas instead of Flash, because Canvas is supported by all browsers and doesn’t require user permission to load; now the graph data is populating as expected.

Error message when trying to save long notes to the fitness Health Bio

We were limiting users to 800 characters in the Health Bio general notes, but did not provide any indication that there was a character limit.
As a quick solution for this edge case, we did the following:

Helper text ‘Max Characters: 500’ was added below the text input for the ‘Explain Text’ to indicate the maximum characters allowed
Helper text ‘Max Characters: 1000’ was added below the text input for the ‘General Notes’ to indicate the maximum characters allowed

Able to create an event prior to 1/1/2000 on the Add Lead page

Previously, we were allowing users who were adding a new lead via the Add Lead page to create an event with a date in the past.
Now, if a past date is entered in the “Date” field, the only option in the “Time” drop-down is “No Availability”, and the option is not selectable.
Since “Time” is a required field, the user is prevented from saving the event with a past date and must choose a date that is either today or in the future.

PT Total Recurring KPI needed update

The PT Total Recurring KPI in the web app was not matching the data seen in the Accrual Revenue Report, and we determined that was due to a missing salesperson ID in the KPI query.
We added the salesperson ID to the KPI query and now the data is consistent between the KPI and Accrual Revenue report.

Able to save a package without a service

Although we weren’t allowing users to create a package without services, we were allowing services to be removed from existing packages, leaving the package without services.
We wanted to prevent users from saving a package without services, so now the code checks for member services when saving an active package.

Invalid email addresses are not caught by validation

Previously, the web app was successfully saving incorrectly-formatted email addresses; for example:

We added validation so that an error message is thrown when a user tries to save an invalid email format, and they are required to correct the format before we will save the data.

More repeated events are seen in the calendar than are set while editing an event

When saving a calendar event after selecting “Edit this and all future events” and changing the Repeat settings, the number of repeated events seen on the calendar is much larger than what was set.
We found that the end date for events set to repeat on Tuesday and Thursday was not saving, so we fixed the issue and now events save as expected.

How can we help?