LDAP Servers: Service account credentials disabled [#1947676]

I am in the process of testing Drupal as a possible CMS for a company's intranet/extranet. As a test environment I am using two virtual machines, a DC and a webserser. Both are working as intended and can communicate with eachother. My knowledge of Drupal is very limited, as I am still looking for the best CMS for this particular project.

During the setup of a new LDAP server configuration, I have to supply credentials for a LDAP service account. However, both textfields are disabled, thus I cannot enter the required credentials. The textfields stay disabled, even after I switch to a different binding method.

Am I missing something here, or is this genuinely a bug? I also installed the 7.x-2.xdev version of LDAP, which had the same issue.

Comment	File	Size	Author
#8	1947676.patch	1.07 KB	johnbarclay
#8
	ServiceAccount_Disabled.jpg	149.74 KB	Bob_Vdl

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

johnbarclay CreditAttribution: johnbarclay commented 20 March 2013 at 12:26

Version:	7.x-2.0-beta3	» 7.x-2.x-dev
Category:	support	» bug
Status:	Active	» Postponed (maintainer needs more info)

I would say this is a bug, but I cannot reproduce it either on add server or update server form. Do you have any other modules or custom theming that might interact with the jquery/javascript?

Comment #2

Bob_Vdl CreditAttribution: Bob_Vdl commented 21 March 2013 at 08:35

Status:

Postponed (maintainer needs more info)

» Active

Thank you for the fast reply, it seems the Drupal slogan is quite correct.

I only just started with a fresh Drupal installation. LDAP was the first module I installed, together with the entity API to get LDAP working. I am running this Drupal installation on a Windows 2008 R2, using Apache and phpMyAdmin. During the installation, I had some issues changing the language to Dutch. Besides the language change, I made no additional changes to the Drupal core.

Now that I know it wasn't some stupid mistake I made, I'll start with a fresh installation on another virtual machine to see if the issue comes up again.

EDIT: The fresh installation has the same issue, even without any language change errors. Any ideas?

Comment #3

johnbarclay CreditAttribution: johnbarclay commented 25 March 2013 at 15:32

No ideas on this. the javascript should enable the fields when the first option in binding method is selected.

Comment #4

Bob_Vdl CreditAttribution: Bob_Vdl commented 27 March 2013 at 10:54

Thank you for taking the time to look into this issue.

I am currently learning to use Drupal as this seemed to be the best solution for the intranet/extranet I have to develop. Although I did not find a way to solve this issue, I was able to use a workaround to test some required functionalities.

So far I'm loving Drupal, and I've only just scratched the surface. If this problem still persists in my new testing environment, I'll do my very best to look into it and solve it.

Comment #5

johnbarclay CreditAttribution: johnbarclay commented 27 March 2013 at 13:08

Its just a couple lines of code the disables them when service account is not selected so its easy to workaround and test for. But its best to figure out the issue or at least make sure its reproducible before removing the lines.

To remove this check, remove the "#states" part of the array in the following 2 places:

http://drupalcode.org/project/ldap.git/blob/1e346a8747a0440726d1ab03f372...

Comment #6

rumenyordanov CreditAttribution: rumenyordanov commented 8 April 2013 at 20:15

I can confirm that the issue appear with fresh installation but only on IE. Tested against IE7-IE9 and does not work. Seems like a generic problem with JavaScript that affects all widgets that have disabled/enabled state based on selection

Comment #7

rumenyordanov CreditAttribution: rumenyordanov commented 9 April 2013 at 04:20

I did fast research and found http://api.drupal.org/comment/36623#comment-36623, if you change the constant to string it does work in IE which seems to be a generic bug with states form element. Not sure if I need to post patch here but if some one is interested I will.

Comment #8

johnbarclay CreditAttribution: johnbarclay commented 9 April 2013 at 05:12

File	Size
1947676.patch	1.07 KB

Thanks. I imagine this one is quite frustrating. Does this patch take care of it?

Comment #9

Bob_Vdl CreditAttribution: Bob_Vdl commented 9 April 2013 at 07:11

I was about to start testing with other browsers to see if the issue persisted. However, rumenyordanov beat me to it.

The patch you suggested seems to have solved the issue.

Thank you both for taking the time to solve this bug. Using IE wasn't the brightest move, but the company I'm doing my internship with uses it as it's default browser.

Comment #10

johnbarclay CreditAttribution: johnbarclay commented 9 April 2013 at 13:34

Status:

Active

» Patch (to be ported)

We are lucky you were the one that found the bug; many people do not follow through on bugs so there is unneeded frustration. I'll commit this next commit.

Comment #11

johnbarclay CreditAttribution: johnbarclay commented 9 April 2013 at 17:43

Status:

Patch (to be ported)

» Fixed

This is committed. It will not need to be ported to the Drupal 8x version because the admin interface will be driven by new core config changes.

Comment #12

rumenyordanov CreditAttribution: rumenyordanov commented 10 April 2013 at 05:45

Great, one issue down, I see this as generic problem that might also affects other contributed modules so we might suggest the fix to be actually in core.