Bug 77409 - problems adding provisioned container using iManager plugin
Summary: problems adding provisioned container using iManager plugin
Status: VERIFIED FIXED
Alias: None
Product: iFolder Denali
Classification: iFolder
Component: Server Admin (show other bugs)
Version: iFolder Denali
Hardware: i586 SLES 9
: P5 - None : Critical
Target Milestone: Release Candidate 2
Assignee: Brady Anderson
QA Contact: Jared Allen
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-12 22:44 UTC by Victor Billings
Modified: 2005-05-11 20:29 UTC (History)
0 users

See Also:
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 (7.68 KB, text/x-log)
2005-04-12 22:45 UTC, Victor Billings
Details
snippet of simias.log from IS&T (1.81 KB, text/x-log)
2005-04-12 22:46 UTC, Victor Billings
Details

Note You need to log in before you can comment on or make changes to this bug.
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