Chance Posted 6 minutes ago Report Posted 6 minutes ago Version 5.12.3, but also present in all the 5.11.n branches that we have used in past. There are three issues encountered when attempting to manage a client's service, selecting the Advanced Options tab, and then attempting to edit service-specific fields. From our understanding, this tab allows admins to edit service-related fields such that when saving the fields, the underlying service module is not involved. There is an image attached showing the output from this Blesta view (admin_clients_editserviceadvanced.pdt). First Error: An error is being shown when trying to save stating that the value for date renews must be greater than the value for last date renewed. We have not been able to figure out why as the dates look valid (aside from the fact that the last renew date is in the future). Since the next date renew is also in the future, we should not be seeing this particular error. Second error: This Blesta view file cycles thru all service fields outputting either a text input or a textarea input, depending on whether or not the service field's value is scalar or not. When a textarea field is output, the jQuery script in this view instantiates that field as an Ace Editor. There is no reason we can see why any module-specific service field should be construed as an Ace editor. Third Error: Because of the way the second error attempts to create an Ace Editor out of a non-scalar service field, as the view loops thru other service fields that are also not considered scalar, ANOTHER Ace Editor is attempted. While the very first field succeeds in editor creation, subsequent non-scalar fields fail. Even throws an error message in the browser console related to the use of the const keyword in Blesta script that is creating the Ace Editors. It appears from reviewing this script in this view file, that Blesta expects there to be only one scalar field and thus only one field needing to be an Ace Editor. Here are the service fields that are involved with this error: member_number=1090 ancestor=7 privacy=a:3:{s:5:"phone";s:1:"0";s:5:"email";s:1:"0";s:4:"usps";s:1:"0";} spouse=a:5:{s:10:"first_name";s:5:"Susan";s:11:"middle_name";s:9:"Kathleen ";s:9:"last_name";s:6:"Delano";s:11:"maiden_name";s:5:"Paris";s:5:"email";s:21:"SusanDelano@email.bad";} The first two service fields are self-explanatory...simple values. The last two though are serialized arrays that the associated service module works with as needed. Since they are not considered scalar, they are being output in the view as textarea controls. Because they are textarea, Blesta is attempting to instantiate them as Ace editors. And because there is more than one, Blesta is successful on the first creation, but any others cause run-time errors (client-side). These field values should be displayed as-is without any added markup or specialized control usage. We can see from the image that it appears the service field values for the last two are potentially muddled when used in an ace editor. While they appear to be malformed strings, they are 100% proper in the DB but are not being loaded properly in this particular view.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now