End Point Manager - not fit for purpose

I’m sorry to use an inflammatory title, but this module is just shockingly bad for a new user.

I’m using version, updated and licensed today.

As per the guide I select “Global Settings”

I have posted a screen cap at http://awesomescreenshot.com/0471u6xzb8

  1. There are two periods on screen (circled in red) beneath the title and Submit buttons - each linked to some functionality. What on earth are these for?

  2. The phone password text inputs are missing (also circled in red) and cannot therefore be entered.

  3. Entering fields and hitting Submit does nothing visible on screen, and no fields are saved (at least, re-entering the Global Settings displays the default.

So much for the “Global Settings”… :frowning:

Next I started to create a template for my Snom phones. Looking at the template form there are a bunch of field. The tooltips aren’t very helpful - generally just a repetition of the label :frowning: and some stuff just doesn’t work (eg click Internal or External on the Destination field and nothing happens).

So I gave up. $39 and half a day wasted…

What browser are you using? I have never seen those fields look that way and we have over thousands of users on EPM and nobody has reported this as a issue.

Same results for Firefox and Chrome.

Nothing to do with the browser tho. Here’s an HTML fragment around the first period.

Global Settings


and for the first missing input the HTML (as reported by “inspect element” for Chrome and Firefox is
The class=error appears to move the field to top left and zeros dimensions the box model…

Are all you other users using the same version…

More… The raw html for the the input fields (as described above) does not contain the class=“error” attribute. So it’s probably being computed by javascript (purely a guess). The periods (bizarre) are sent in the HTML though…

So, Running it through a debugger reveals that the line 21 of js/global.js

$(document).ready(function() {

invokes validatePass()
There’s a bug on line 5 of global.js that checks passInfo[‘field’].length > 0 and it should test passInfo[‘field’].val().length (as it does on line 6)

Coupled with the two spurious (crazy) periods and this bug I’d say your testing isn’t working (you do test before release don’t you?)

Hi there.

Yes we do test on every release, but it is a limited scope test. You have to consider the scope of the module. If we tested every single part of Endpoint Manager you wouldn’t see releases for 6 months while it went through QA. At $40, the module would never make profit and would never see the light of day. There’s just so much involved in a module like this and I don’t even work on it. I work on the free ‘sister’ version and that’s hard enough. Supporting over 275 phones can be extremely time consuming in itself and bugs will always slip in at this level. The thing about this module is you won’t find anything at a comparable level. Even in other VoIP software from competitors. Why? Because no one wants to waste time on the headache of this. We are lucky enough to have Luke and that Schmooze fronts the bill for this module (where Luke works on it 30 hours a week, if you consider the cost of a decent programmer in the US and how many people buy it at $40/week we are at a complete loss on this module internally).

I’m not making excuses here for the software, I am just asking you to look at it from a different perspective and what we provide vs other software in the market at the same price level.

Again thanks for the bug reports. We strive to make this a worthwhile program and we hope that in the future you will feel that the $39 you paid is justified.

Mark, thanks for your feedback on the module, All commercial modules include free support on bugs found on the product. To report a bug please open a bug report at http://issues.freepbx.org , once the bug report has been received and the bug is confirmed we will make all reasonable attempts to resolve the bug in a timely fashion.

As Andrew stated, there is a lot of stuff going on in this module and unfortunately cannot have everything tested on every release.

The periods are for debugging purposes, and were not supposed to be noticed (great attention to detail by the way).

Why your input boxes are getting the error class I do not know. I am unable to reproduce it on any of the boxes I have access to. Would you be able to open a bug ticket with login credentials so I can see what is happening on your system? Without that, I can only suggest using a different, up-to-date browser and making sure you do not have the OSS Endpoint Manager installed. Then a removal and reinstall of the Commercial EPM.

What Luke means is a support ticket at support.schmoozecom.com where you can provide us login details securely.

I did look and we have well over 2000 systems on your same version and we can not re-create those issues anywhere.

If you have 2000+ systems running the same code as me then you have 2000+ systems where the users are :-

  1. Prepared to tolerate debugging ‘features’ that can have unknown results presented in front of an unsuspecting user. If you must ship debugging code in a commercial product the at least allow the developer to provide a GET parameter that enables it explicitly.

  2. Running bugged code. Tomorrow (it’s 1am here) I’ll file a Jira issue but I have already indicated where the fault is (line 5 of global.js) where the coder has erroneously tested
    passInfo[‘field’].length > 0 rather than passInfo[‘field’].val().length > 0
    You can try all you like to recreate my symptom but what the coder has done is wrong. Two lines later he does a similar, but correct, test.

I’ll have to punch a hole in our firewall to allow remote access, but if it’s really necessary I will…

Regarding testing, I understand that you do limited domain testing. So do we sometimes. But this is at least three (3) faults (remember the submit button is ineffective too) on the first screen… Why not investigate Selenium to perform automated regression testing of your UI. Hooked up to a CI service like Jenkins it’s a no cost, no effort, way of preventing such regression errors.

$39 or $1000, commercial software is just that and shouldn’t carry trap doors nor rudimentary coding errors that prevent function on the first screen.

Why your input boxes are getting the error class I do not know.
I have already indicated where the fault is (line 5 of global.js) where the coder has erroneously tested passInfo['field'].length > 0 rather than passInfo['field'].val().length > 0

We also welcome more community coders to the FreePBX project. Seems you are full of wealth and great ideas. For the record we run 6 jenkins servers already and have a bamboo server being put into production shortly.

Anyways you might want to think about how you attack people and comment on things in the future. Attacks wont get you far in this community.

Please feel free to open a support ticket with us. This thread has now been locked to keep it from turning into a flame.