Bug 77409

Summary:	problems adding provisioned container using iManager plugin
Product:	[iFolder] iFolder Denali	Reporter:	Victor Billings <vbillings>
Component:	Server Admin	Assignee:	Brady Anderson <banderso>
Status:	VERIFIED FIXED	QA Contact:	Jared Allen <jpallen>
Severity:	Critical
Priority:	P5 - None
Version:	iFolder Denali
Target Milestone:	Release Candidate 2
Hardware:	i586
OS:	SLES 9
Whiteboard:
Found By:	Component Test	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	customers simias.log where they attempted to provision an org snippet of simias.log from IS&T

Description Victor Billings 2005-04-12 22:44:31 UTC

Build : public beta

Description : customer attempted to add an org as a provisioned container and
was unable to. Checking the Simias.log shows "Invalid objectClass: Partition" or
"Invalid objectClass: organization" This was duped by Ron Randquist in IS&T as
well. 

Steps to reproduce : 
1.do not provision a container upon install of iF3e
2.enter iManager and add an org as a provisioned container
3.view the Simias.log for details on the failure

Expected Results : This should add the O without problem.

Actual Results : The customer is unable to provision an entire org, they are
only able to add ou's or groups. 

Additional information : See attached Simias.log and attached log snippet for
more detail.

Comment 1 Victor Billings 2005-04-12 22:45:19 UTC

Created attachment 33958 [details]
customers simias.log where they attempted to provision an org

Comment 2 Victor Billings 2005-04-12 22:46:27 UTC

Created attachment 33959 [details]
snippet of simias.log from IS&T

Comment 3 Scott Reeves 2005-04-27 16:47:46 UTC

Looking at the log files and the code it appears the problem is that the 
object class type is coming back as “organization” rather than “Organization”. 
I don't have this reproducible anywhere so I am not sure of this but I think a 
case insensitive compare might resolve the problem. This is assuming that LDAP 
does not require case sensitivity on these names – otherwise this is an LDAP 
bug.

Comment 4 Brady Anderson 2005-05-02 23:34:52 UTC

Changed the code in LdapSync to always perform a case insensitive compare when
comparing object class types to the internal literal strings.

Comment 5 Victor Billings 2005-05-11 20:29:57 UTC

this is tested fixed in the beta 5 build