Today I downloaded and attempted to upgrade a few modules
When I hit the Apply Config button I get this message
**“Unable to locate the FreePBX BMO Class 'Sipsettings’A required module might be disabled or uninstalled. Recommended steps (run from the CLI): 1) fwconsole ma install sipsettings 2) fwconsole ma enable sipsettings”
I tried fwconsole reload and the same thing
I tried the commands it recommends in the error message and got an Exception Trace. (I’ll copy and paste it if needed)
I just wanted to add that every FreePBX system I manage had this occur, so it’s definitely a bad patch. You don’t need to enable – just run “fwconsole ma install sipsettings” and the portal should be functional again.
For those curious, this happens a lot on dev systems but shouldn’t happen elsewhere.
if you only change the version in the module.xml the system will see the module as new but assume the install code hasn’t been run for the new code. So the system disables the module. If a module is downloaded but cannot install it will sit in this state. I am guessing there is a weird dependency thing somewhere and it prevents sipsettings from being installed during the update. The dependency is ultimately resolved because people can run the install on sipsettings after.
If this is happening in multiple places it may be worth a ticket but you would have to have a way to reliably reproduce it.
What was added was a dependency to a version of backup which makes no sense because the module literally does all the work 15+ but hey what do I know…
<module>backup ge 15.0.19</module>
Anyway that is likely the dependency failing that is mucking things up
I haven’t found a system yet that wasn’t impacted, so I’m sure Sangoma must be aware. It’s funny you responded because I’m working on your softphone as we speak. If we send a SIP MESSAGE out of the PBX to the ClearlyIP softphone, we get a 501 Not Implemented. Any chance of supporting that in the future?
That would be something to contact support about with specifics about what you are trying to accomplish. Most of the communication with the app is done via push messages so there may be a different way to accomplish your goal. They also can direct any feature request to project management
Yeah one of our people popped in to our chat today at work. Hos one test box had this issue. Whoever added the backup dependency should be flogged. In any case this will probably be seen a lot more as systems update this week.
Both sipsettings 15.0.9 and backup 15.0.19 were promoted to STABLE within a few min of each other early in the morning on July 19. If there is a race here caused by a module dependency in EDGE, then I don’t think that’s it.
No module should depend on backup by design. That said this could be a bug in dependency handling. Perhaps even an edge case that has been around a while. The dependency being added is what seems to be causing this but may not be the root issue. Backup should simply install first and it isn’t. This is likely a bug in framework. The only dependency in backup is filestore. I haven’t looked at that but perhaps filestore needed an update so backup was pushed back behind sipsettings. I honestly haven’t looked at the dependency code in like 10 years. This requires someone to sit, break it, and fix it repeatedly to debug what is falling in it’s face. This is why I also mentioned needing a solid reproduction path so it can be repeatedly and consistently put in this state to find and test a fix.