I found this thread and this thread about the same thing, but they’ve been idle for the draconianly-short 7 day timeout, so I can’t reply to either.
A FreePBX 15 server I manage died a few days ago – catastrophic storage failure. So I restored its most recent backup to a new build of FreePBX 17. Among a litany of other issues, I discovered that EPM no longer works right. When I try to create a template (I haven’t tried much else), I get a “whoops” error, that indicates that a column is missing.
In order to figure out what columns should exist, I had to create a brand-new FreePBX 17 server, to see what columns exist in the endpoint% tables, and then diff that against what I currently had (as a result of the FreePBX 15 → 17 migration).
In my case, the following SQL statements cause the table definitions to match what the fresh-FreePBX-17 database had:
ALTER TABLE endpoint_basefiles MODIFY `model` varchar(2000);
ALTER TABLE endpoint_customExt ADD COLUMN `transport` varchar(20);
ALTER TABLE endpoint_templates ADD COLUMN `plarNumber` varchar(255);
ALTER TABLE endpoint_templates ADD COLUMN `plarTimeout` varchar(2) DEFAULT 0;
ALTER TABLE endpoint_templates ADD COLUMN `ldapFNameFilter` varchar(100);
ALTER TABLE endpoint_templates ADD COLUMN `ldapLNameFilter` varchar(100);
ALTER TABLE endpoint_templates ADD COLUMN `ldapSearchFilter` varchar(100);
ALTER TABLE endpoint_templates ADD COLUMN `ldapDialStringsToggle` varchar(2);
ALTER TABLE endpoint_templates ADD COLUMN `ldapDialStringsConfig` varchar(4096);
ALTER TABLE endpoint_templates ADD COLUMN `phonesWebUIToggle` varchar(2);
ALTER TABLE endpoint_timezones MODIFY `snom` varchar(255);
ALTER TABLE endpoint_timezones ADD COLUMN `fanvil` varchar(5);
I noticed a comment in one of the previous threads that the previous version (15 something) was out of date, and to upgrade to the latest, before taking a backup. I don’t know what version of EPM the FreePBX 15 server was running, but it should have been the latest version; the backup file doesn’t seem to record installed module versions anywhere, at least that I’ve found so far. And while that comment was made with the best of intentions for that specific situation, it’s not acceptable from a software development perspective. And from a sysadmin perspective, it is downright crazy that modules don’t verify that their schema is as expected. (And fix it, if needed, or at least make it obvious exactly what’s wrong.)
Creating these columns in the manner I have doesn’t necessarily accomplish the exact same net effect as what the developers might have intended; if they were executed in a different order or with different syntax, the defaults might be populated differently, or there might have been computed values, or… who knows, there’s no end of possibilities here.
Does anyone know what the database migrations actually should be? Is there anything more than merely creating the missing columns (and resizing existing ones)?