Multiple bugs: DB wiped on module disable/enable, TemplatesUsers not used for config generation, Yealink phonebook not delivered to phone

[emassen]

MikoPBX version: 2026.2.118
ModuleAutoprovision version: 1.66
Phone models: Yealink T21P_E2, T31P, T22P, T23G, T20P

Bug 1: m_ModuleAutoprovisionUsers is wiped on module disable/enable
Every time the module is disabled and re-enabled via the MikoPBX interface, the table m_ModuleAutoprovisionUsers is completely wiped. The table m_ModuleAutoprovisionDevice is preserved correctly.
Steps to reproduce:

Have records in m_ModuleAutoprovisionUsers
Disable the module via MikoPBX interface
Re-enable the module
Check m_ModuleAutoprovisionUsers — it is empty

Expected: Data should be preserved across disable/enable cycles, similar to m_ModuleAutoprovisionDevice.

Bug 2: Config generation still uses legacy m_ModuleAutoprovisionUsers, ignoring m_TemplatesUsers
The new m_TemplatesUsers table is populated correctly via the web interface, but Autoprovision.php::generateConfigPhone() still reads from m_ModuleAutoprovisionUsers to resolve the SIP extension. The m_TemplatesUsers flow (getConfigStatic) is only used for URI-based templates, not for the main PnP provisioning flow (/getcfg endpoint).
Steps to reproduce:

Add a phone mapping via the web interface (Configurações do telefone tab) — this writes to m_TemplatesUsers
Phone requests config via /pbxcore/api/autoprovision/getcfg
Config is generated using m_ModuleAutoprovisionUsers, not m_TemplatesUsers
If m_ModuleAutoprovisionUsers is empty (see Bug 1), phone receives default apv-miko credentials instead of its SIP extension

Expected: The /getcfg endpoint should use m_TemplatesUsers as the source of truth for MAC→extension mapping, consistent with the web interface.
Additional finding: The userid field in m_ModuleAutoprovisionUsers maps to m_Extensions.userid (not m_Extensions.id). This is undocumented and caused significant confusion during manual data migration.

Bug 3: Yealink remote phonebook not loaded on phone (Content-Type: text/plain)
The /pbxcore/api/autoprovision-http/phonebook endpoint returns Content-Type: text/plain instead of text/xml. Yealink phones reject the phonebook XML with error ret=23 (CURLE_WRITE_ERROR) because of the wrong Content-Type header.
Steps to reproduce:

Configure remote_phonebook.data.1.url pointing to the phonebook endpoint
Phone attempts to download the phonebook
Syslog shows: [DCMN]Recode is 0, Request err. / [DCMN]durl thread: ret=23 Error

Fix: Change line 439 of GetController.php:
php// Before:
$this->response->setHeader('Content-type', "text/plain");

// After:
$this->response->setHeader('Content-type', "text/xml");
Additional finding: The <Title> tag is required inside for older Yealink models (T21P_E2, T20P). Without it, the phone logs Item List Node Not Found and discards the phonebook. This tag is now present after our fix to GetController.php (adding $phoneBook.= "\t<Title>{$key}</Title>".PHP_EOL;), but the Content-Type issue still prevents delivery.

[emassen]

Bug 4: Yealink phonebook download fails — Transfer-Encoding: chunked not supported
The /pbxcore/api/autoprovision-http/phonebook endpoint returns Transfer-Encoding: chunked (no Content-Length header). Yealink phones (tested on T21P_E2 and T31P latest firmware) fail to download the phonebook with:
[DCMN]set option fails, option is no support.
[DCMN]Recode is 0, Request err.
[DCMN]pipe write error, end transfer
[DCMN]durl thread: ret=23 Error.
Root cause: The phonebook XML is generated dynamically without a known size, so nginx uses chunked transfer encoding. Yealink's internal curl implementation does not support chunked responses for remote phonebook downloads.
Expected: The response should include a Content-Length header. This can be fixed by either:

Buffering the phonebook response and returning it with a known Content-Length
Adding chunked_transfer_encoding off; in the nginx block for the autoprovision endpoint

Workaround tested: None found on the phone side. Fix must be server-side.