OSS Endpoint Manager no longer loads packages after upgrade to 13.0.2

I had what seems to be the same issue, and was able to fix it. it seems that there is an older (?) version of Javascript running in Chrome.

I had to go through the epm_advanced.js, epm_global.js and epm_???.js and change all the
function functionname( parameter = defaultvalue)
{ …
}
lines to
function functionname( parameter )
{
parameter = typeof parameter !== “undefined”? parameter : defaultvalue;

}

I’m not quite sure how to update the code in the repository (GIT?), but I’m sure that there are a few smart cookies that can do it.

Chrome actually runs the latest versions of the v8 javascript engines: V8 (JavaScript engine) - Wikipedia

Firefox uses spidermonkey: SpiderMonkey - Wikipedia

The thing you have to understand about how javascript and html5 work is that publishers have their own versions of the specs they implement. So Firefox and chrome implement different features. Doesn’t mean one is running a lesser version of javascript though.

Once you stated this error I was able to figure out the issues by looking over this document: Default parameters - JavaScript | MDN

Parameters with defaults set are not supported until chrome 49 (which is what I am running) but Firefox has supported them since 15.

Removing the parameters to make it work is also not a recommended fix since you are now sending undefined variables around.

Ok chrome has updated to 49 overnight and seems to work. but as 49 was only released on 2/march, the expectation that every user will be using the very latest of in your case a Beta version is not a good idea and as this issue was started before 49 was released it wouldnt as has been said worked on the current version of chrome at that time.

as to

◦ restapps <<<<<<<< THIS IS WRONG SHOULD BE PHONE APPS
No because the module’s rawname is “restapps”

yes the raw name is restapps but in module admin the name is Phone Apps again the assumption is that a user will know the rawname is restapps and as there are modules called Rest API and Asterisk REST Interface Users though the rawname for the module to be disabled is restapps this isnt referered to in the name or info section for it.

Firstly @tm1000, many thanks for all your help here. Glad we managed to figure out what was going on!
Now onto some responses to the above.

Thanks a lot. Is there any workaround for this? At the moment I can’t save any changes on the server with this message.

Is this what you’re looking for? I had it working last night like I mentioned using Firefox and on OSSEPM Beta, but now having switches back to Stable, I’m getting the following and cannot select a model from the device page.

Hi there,

I’m having also the trouble getting the message “Can’t Load Local Endpoint Manager Directory!” on our systems after installing the stable version 13.0.6.6 of endpointman. Switching back to Beta and installing 13.0.6.2 there are no problems. Out of curiosity, if our systems are broken, I installed in a VM the FreePBX distro vanilla and experience the same.

My wild guess is, this started with commit fbe184d1d50a5cb0579a58b0699bb283db6b98ff at github at endpointman.

Here is how to reproduce:

  1. Download and install current FreePBX distro
  2. Set up admin user and login to FreePBX Administration web site
  3. Go to module admin and
    3.1. disable Phone Apps -> process
    3.2. disable EndPoint Manager -> process
    3.3. install OSS PBX End Point Manager -> process
  4. go to Applications -> Extensions
  5. Add new PJSIP extension
  6. enter extension number, name and set all to no at ‘other’ tab
  7. click submit

Expected result:
Extension created

Actual result:
Blank page with “Can’t Load Local Endpoint Manager Directory!”

Workaround is disabling endpointman, creating the extension and enabling it again.

Those timezone problems reported by @rwllr above also appears at this fresh FreePBX install with any browser at Linux and Windows. I don’t have this timezone problem at a fresh AsteriskNOW install, upgraded to the latest FreePBX version, but still see the “Can’t Load Local Endpoint Manager Directory!” problem.

Our systems are also AsteriskNOW installations upgraded to FreePBX 10.13.66-9… There are already Polycom and Aastra phones configured. Trying to edit templates with endpointman 13.0.6.6 also leads to “Can’t Load Local Endpoint Manager Directory!”.

We downgraded to Beta version 3.0.6.2 to being able to use the module.

Yep we are seeing the same.
its because of

   //define("UPDATE_PATH", $this->global_cfg['update_server']);
    define("MODULES_PATH", dirname(dirname(dirname(__FILE__))) . '/'); **<<<<< was commented out**

    //Determine if local path is correct!
    if (file_exists(MODULES_PATH . "endpointman/")) {
        define("LOCAL_PATH", MODULES_PATH . "endpointman/");   **<<<< was commented out**
    } else {
        die("inc file - Can't Load Local Endpoint Manager Directory!");
    }

im sure there are other bits but so far found these 2 bits and this lets you create templates and make extesnions.

as to
Whoops\Exception\ErrorExceptiondate_default_timezone_set(): Timezone ID ‘UTC/UTC’ is invalidFile:/var/www/html/admin/modules/endpointman/Endpointman.class.php:90
This is something I will get the developer to address

set this in advanced freepbx setting , its also used by time conditions now as well as teh server time , we have seen some oddities on times if not set

Those are commented out because they create fatal errors.

Not on the the versions tested here, with them uncommented no errors when creating extensions or using ossepm
Can you say where the fatal error occurs so I can check here.

Sorry I can’t recall.

There is a new version released

Hi

Ok upgrade to that version and looking at the diff it fixes the bits i mentioned. so looks like it may be a goer.

Sorry its been a headache but we have a lot of servers using it and with it broken was holding up a migration.

the only headache now is getting the customer to upgrade chrome…

This was already addressed. If you looked at the diff you would have noticed that.

The module is unsupported. Sangoma does not support it. Please keep this in mind.

Thank you for the fix. It works.

Pardon me, but that is a very poor approach to any sort of OSS project. Its hard for me to imagine a more irresponsible act on the part of a project maintainer than to push code that has not be throughly vetted by the project maintainer. AAMOF there are subtle undertones of “get the supported (aka closed source) version if you don’t like it” in the suggestion that those using the “community maintained” version must “wait” upon the provider of buggy code to correct the problem.

So you’re running Git… just revert the bad work and be done with it.

What it may be, if you read between the lines, they may be suggesting that more of the interested parties to get involved in development, testing (with emphasis on testing) etc. because Sangoma employees’ responsibilities don’t extend that far. Sangoma employees are primarily charged with responsibilities towards their product and that is quite understandable, and they are really good at it. It is ultimately their good will, that they give the non-Sangoma-supported modules a glance and fix them when needed.

That certain OSS modules suffer from neglect and high churn, is because of, ultimately, the ‘mode of usage’ on some of them: they are usually downloaded once, if they mostly work they are left that way, because development, testing and care for them requires mostly 3 things: time, time and more time. And certain knowledge that not everybody has. And let’s not forget, dedicated infrastructure. And (since interested parties are usually admins of certain parts of company networks) their management may also need to be involved. Who may, or may not understand, why the involvement is important or even who the hell is the open-source movement. Or may be ‘contractually bound’ to not let anything out that may help competition, even in broad sense. Or may not want to undermine Sangoma’s business model.

Bottom line ? Unless you are seriously so financially-constrained, that you really can’t afford the non-free modules, and you’re your own operator, admin and manager, and you know what you’re doing, you’d probably be easily steered towards the non-free solution, that ‘just works’.

This is not your ‘general purpose’ operating system or some libraries that everybody needs and everybody can get on board with - FreePBX is a highly specialized system; Hacking in it is not a feat of some ‘random geeks’ any more, even if it is still possible in Asterisk itself.

(Disclaimer: I am only using the Distro as a customer, running on ‘free-as-beer licenses’ where possible without compromising on features, and I fall into the mostly not-enough-time-resources-and-knowledge category when it comes to involvement in development… and so far, when support was needed, Sangoma was exceeding my expectations every time, and gone the extra mile even though I only ever actually purchased a couple of phones)

I take issue with the wording choice here. There are many things which are orders of magnitude worse that publishing untested code, and your choice of the word “push” makes it appear as if users are somehow being forced to use the OSS EPM. Wording aside, your sentiment is essentially correct, the project maintainer(s) should test their code. The issue is that the OSS EPM project is community supported, and at present, there is no community supporting it. You seem to feel that the absence of such a community automatically puts the onus on FreePBX developers to maintain it.

So there is a dilemma here, does FreePBX publish less than perfect code and run the risk of annoying users with known bugs, or do they not publish the code and run the risk of being accused of suppressing the project to promote the paid version. The decision has been made to publish the code and make it clear at every opportunity that the OSS EPM is community supported.

I wrote a lengthy post the other day about this module which is vaguely related:

As to your objection to the word “push:” Linguistics is a wonderful thing. “Push” is a Git command whereby one transmits changes from one Git repository to another. It is a term that the maintainer will certainly understand (and most other developers as well).

Objecting to pushing untested code in no way implies what you have assumed. It is irresponsible, period. Developers of any kind understand that. Untested code always goes into a testing branch of some sort. It sits there until someone tests it and verifies that it does not break currently working functionality. In this case, since there seem to be no community developers, it would sit there forever. That is very much preferable to pushing it to the current stable branch and causing pain for the community users.

Pushing code is a few second job. If the maintainer has time to push code to the stable branch, the maintainer has time to push it to a testing branch. The existential fact of the push provides self-evident witness to that fact.

Sure. But I am not the maintainer.

Users have complained both ways. They have complained that we do not update OSS and then when I publish updates from a community member they complain that it doesn’t work.

So it didn’t work before and it doesn’t work now. There’s no difference.

The solution is easy. If you are this riled up about OSS EPM then do something about it and go fix it yourself.

Good attitude. I think I see why the OSS version is pretty much dead.

OSS is dead because there is only one person working on it. By himself. With no outside help from the community. That person is not me.

You are looking way too deeply into this. The last time I asked people to “step up” they did, which is why a community contributor now exists. If you have problems with OSS EPM you should talk to him. He is the maintainer. Not Sangoma and not me (you replied directly to me).

What’s really sad is when we ask for help from the community to support projects like this, with time or other resources and instead the blame comes back to the “maintainer”. The project needs help. And if you have a problem with the fact that OSS is unmaintained or you think there is some plot to make you buy the commercial EPM then please remember that there are over 127 active modules in FreePBX. 100+ of those are free, open source and maintained by Sangoma.