Fully patched/up to date v16 system. The Renew Now links don’t add anything to the cart (yes, I’m logged in). Please fix. And please do better testing. SO frustrating.
While you’re at it, can you please make a button/link to renew expired modules where they are listed??
I honestly never use this, I just do everything through the Sangoma portal. What does the link actually take you to?
Here:
If I could figure out how to put an update renewal in the cart for a deployment, I’d do that. It can’t be done from the deployment and I don’t see update renewals in the store.
It appears that the link you are clicking just takes you to your online account and doesn’t do anything special with preparing the cart for you.
I will normally just find the license by searching through the store, then clicking the “Renew” button.
That’s correct. It used to work as expected.
I figured out how to renew updates. When I saw below I assumed it was to renew the license, since that’s the product. It’s not. When you click “Renew” it opens a report for ALL commercial modules for all deployments on your account.
Next malfunction. Order status says licenses have been added to the deployment.
However, the deployment disagrees, even after a Activation Update.
I am normally able to see orders within 15 minutes after clicking Update Activation.
PM Sent - I’m here to help.
Hey @mwhite what is the best practice for renewing licenses? Posting it here for posterity would be useful.
@mwhite , thank you. And…taking an hour or more and needing assistance to renew maintenance on a module is a significant problem. We bill by the hour and can’t send an invoice for a $25 maintenance renewal with $200 in labor. So when things don’t work because of inadequate testing (like the renew button in FreePBX going to a generic page), you are cost-shifting onto us: You didn’t spend money to test, so now we have to give up billable time to figure out what’s broken and how to fix or work-around it.
As you know. this is/has also been the issue with SangomaConnect renewals. It puts us in a really bad bind where we have to eat time or irritate customers.
Same issue. Beyond frustrating. I also bill clients by the hour and have been unable to discern how to update EPM on several Cyberlink installations, not to mention upgrading those installations to FPBX apparently requires purchasing a second Cyberlink install and then migrating settings over. And the support wiki is vertually useless now.
This is not ok. I’ll review with my team and work with biz sys to get this reviewed and improved.
Nenad
But it clearly IS okay, but stuff like this keeps happening and it’s getting worse, not better.
And the people who dare mention it here have been banned, blocked, deleted, forked, ad nauseum. If you want to show people it’s not okay, fix your code quality and fire whoever setup the current non-function loop of bad code and inadequate testing.
Many of us are well past the point where lip service has any meaning other than an insult. FIX YOUR CODE.
Thanks @ncorbic. I’m interested in what you can come up with to resolve the issue. Perhaps there is a better way we should be renewing licenses?
I think the community should be leaned on to provide feedback for this process. Looking forward to your response.
Thanks Ncorbic for your attention to the issue. Any idea on when the support wiki/help file links will work again instead of just taking us to a generic page of all support/help articles?
And what would you suggest as to migrating from 16 to 17 on Sangoma Cyberlink hosted installs - besides having to purchase a SECOND CyberLink license which will change the IP and require resetting several 3rd party addons as well - not to mention having to update all of the phones with the new address. Or backing up the settings, deleting the current 16 installations, and installing 17 (is there a procedure to even install 17 with Debian on Cyberlink?) which involves several hours of downtime. I work with large medical practices and urgent care centers that require 24/7 phone service, including with Zulu and Sangoma Connect for the doctors and remote staff.
Hi @FreerPBXer I hear you loud and clear. Frustration is evident in your response.
We are reviewing the whole process and are prioritizing it. FreePBX team works together with BizSys team that is in charge of the portal, it seems that bunch of thing fell through the cracks.
Would you be open to a screen share session where you can show us the causes of frustration or record your screen on what you are trying to do. You can email me directly at ncorbic @ sangoma.com.
Hi @chuckjuhl we never had inline upgrades. The good news is that after FreePBX 17 and onwards we WILL have inline upgrades and you will never have to migrate this way again. This was one of my main motivations to moving to Debian. We have the same issue on PBXact cloud where we have migrate over 500 instances: we have to backup, restore in new vm and restart with same IP. We do have a FreePBX cloud migration module that will do the full migration for your between two systems and you can try to do that. However you have to work with Cyberlink to retain or migrate your IP.
I will talk to my team if there is something else we can do.
Nenad
No. I’ve been extremely clear for months that we cannot afford to be Sangoma’s uncompensated testing department. You are software developers. Testing, finding your own cracks, is a key part of that and you’ve not been doing it well enough for FreePBX to stay viable for us to deploy.
I have repeatedly said as much. I have repeatedly asked for you to publish both your testing regimen, and a list of known bugs with module and core releases. I’ve asked for refunds for defective hardware (and been ghosted by Mike and Ryan), I’ve asked for apologies for abusive treatment/moderation here.
Sangoma seems to have zero qualms about asking for free stuff. All we’re asking for is code and handsets that work, and respectful treatment.
Actually we were always able to upgrade versions from 14 to 15 to 16 with the cloud installations using the upgrade modules. Not sure what you are referring when you assert that there has never been inline upgrades.