Function processLDAPValues (values) does not return any values in Thunderbird 68.3.1 and later
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: marinar, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763
Steps to reproduce:
The configuration script is used to set user profile.
Thunderbird\default\prefs\autoconfig.js points to Mozilla.cfg file that loads/run configuration script from web server.
In Thunderbird 68.3.1 and later, the function processLDAPValues (values) does not return any values. No problems with this function in Thunderbird 68.2.2.
Actual results:
Configuration script sets all preferences values except ones that returned by function
processLDAPValues (values)
Expected results:
Function processLDAPValues (values) reads user attributes - displayName, mail and sets preferences
lockPref("mail.identity.id1.useremail",emailaddress); lockPref("mail.server.server2.name", emailaddress );
lockPref("mail.identity.id1.fullName", fullName );
Any advise.
Any new features or settings introduced in ver. 68.3 blocks function processLDAPValues (values)
|
||
Comment 1•4 years ago
|
||
Reporter,
Do you see this also when using version 78?
|
||
Comment 2•4 years ago
•
|
||
Marinar, thank you very much for reporting this and bug 1662433, and our apologies for the inconvenience!
Pls do keep advocating for this to get fixed.
(In reply to Wayne Mery (:wsmwk) from comment #1)
Reporter,
Do you see this also when using version 78?
Yes, as reported by same reporter in bug 1662433.
Following my advocacy wearing my enterprise support hat, Bug 1592922 has fixed a part of this problem related to LDAP Api and sandboxing. There's also a sandboxing pref which plays a role here. However, according to Mike Kaply's research on bug 1592922, on top of the sandbox MCD-API issue, there's an outstanding bug, apparently regressed by LDAP bug 1576364, currently tentatively tracked in reporter's bug 1662433. So I think in terms of bug management, maybe better to focus our efforts there.
Description
•