Licensed module access blocked without active maintenance?

I’m trying to understand what was paid for when a 25 year license was purchased for this module, which now cannot be used because the additional maintenance fee is expired. Can a Sangoma person please explain? This is a recent change in behavior…maintenance has not, historically, been required to use licensed modules.

I don’t fully understand but there is some new mechanism in place to prevent the module from being configured. It was discussed here - Why are you bugging me for a module I am not even using? - #19 by penguinpbx

The module continues to inject itself into your call flows. But the web interface is blocked from making changes or viewing current state of the module’s configuration.

The screenshot you provided is missing some important information. What versions of which module(s) are you running and when did the maintenance expire ?

Please refer to the related blog post and associated forum topic from a couple of months ago that introduced the change in behavior: Avoid walking the plank with expired modules

That remains the case for validly licensed commercial modules – you can continue to use any version of the module that was available during your active maintenance period.

You know what this blog and any other conversation about this is missing? What is the actual grace period? They update framework to the version that has these new changes what is the grace period time frame before their “licensed” modules end up stop working?

Even more importantly, was there ever an announcement about this emailed out? Because a blog post and a forum post without alerting people that don’t look at blogs or forums means a huge chunk of the user base is unaware of these changes.

Kind feels like Sangoma is just going to upset their users (yet again) over a poor roll out and implementation to solve a problem that rarely happens. But hey, I’m sure the measuring contest is worth it.

Currently, the grace period lasts one month from the moment the problem is initially detected on a deployment and the user is informed of the same via email and/or dashboard notifications.

Yes. Affected users may have received emails, similar to module update notifications, depending on their configuration.

If you believe that this is “a problem that rarely happens”, then that doesn’t seem to be in conflict with “a huge chunk of the user base is unaware of these changes”. Indeed, this is a bit of a tree falling in the woods problem :evergreen_tree: :hairy_creature: for the vast majority of users who only use official Sangoma FreePBX mirrors with active commercial module maintenance for security and other updates.

Please @FreerPBXer post a full screenshot with the requested information:

Let’s see if I understand this:

Your code defect reported module updates for commercial modules where maintenance had expired, and let them be installed. Systems ran like this for years.

Then you disabled those modules entirely, changing years-long behavior and causing system outages for your customers.

And because you sent renewal notices before doing this it’s all okay?

I must have missed the part of the communication that provided direction to back-grade to the version these systems can still run. You did communicate that as an option and provide directions, correct?

No. Sangoma made a serious fundamental change to how modules function. Why wasn’t there are full announcement to let everyone know this major change? You are literally changing expected behaviour of people’s systems.

This, much like other things in the past, needed to be communicated better.

No, they are not disabled entirely. They just disable the GUI interface. Each time you hit “apply config” or “fwconsole reload” the modules still function as normal. You just can’t MACD anything via the GUI. And this should only impact you if the module version you are running is newer than what the support maintenance version lock has. At least, in theory.

Automatically letting you know about the existence of security updates via convenient in-GUI Dashboard notifications and emails sounds like a really cool :smiling_face_with_sunglasses: feature (that’s existed in FreePBX for many, many years.)

For over a decade, that has NOT been the expected behavior when upgrading minor versions of modules on existing systems using only the official Sangoma FreePBX mirrors. Please share your mirror change history, if any, and see the old links in the below comment from last month on the same topic:

…specifically this link from 2016:

…and this link from 2017:

Again, @FreerPBXer please share which modules, versions, and dates you are referring to because your only screenshot thus far of the “Module Access Blocked” dashboard notification message lacks this important information.

Despite not agreeing with every word selection, Good current theory! That is exactly how things should flow right now in most cases.

Analysis of the problem notwithstanding, if you:

…and are looking for the solution when seeing a “user interfaces disabled” message like your screenshot – assuming there isn’t some other matter at play, which is hard because of lack of details in that screenshot – then you should follow step 5 of the previously mentioned blog post:

  1. Update any commercial license purchases via portal.sangoma.com (if applicable.) :pineapple:

(Slightly aside, this step is currently difficult if you see that Portal.sangoma.com down?)

And yet it’s been happening for years..and you don’t expect it? The mirror question is just more of Sangoma blaming the end user. And you wonder why we don’t deploy FreePBX any longer.

As with the ongoing failures breaking scheduled backups (which go back years and years) and the ongoing failures of the backup and restore module (which go back years and years), these systems are PLAIN VANILLA. The only module we have ever deployed outside the Sangoma stack is for ClearlyIP, and we’ve done that because the service and support for Sangoma’s SIPStation trunking became intolerably awful.

You can argue and debate and belittle your customer and change the titles of their threads all you want, and you can probably technically win. But in the end Sangoma loses because it drives away those who are evangelizing for its products. At some point you have to decide if you want to keep trying to be right, or if you want to get what you want; you can’t have always get both.