When we export a document (IQA query, business object, content, content type, etc.) today, if that document has custom permissions it will not import into a database that didn't already have that content with custom permissions.  This comes up in the following scenarios:

• Create a new query in Dev, set permissions, test, copy to production.
• Create a generic iPart with permissions, import to new clients.
• Modify the ACL for a query to include a new Role in Dev, then import to Test.
• Import new Nav items we've set up in Dev.

Beside all that, we often have to apply the same permissions over and over to multiple items.  Having our own predefined security sets would make this a lot simpler.  (It would also keep the Access* tables from growing excessively, since each "custom set" is assigned its own key.)

I'm in the process of building an AJAX-y search for edit field in a larger form.  The lookup needs to use IQA queries from a particular folder (configured property of my iPart).

I'm hitting a snag in the following part of the code.  (code includes "using Asi.Business.Common")   The error I'm getting (exception I'm catching) suggests I don't have permission to that folder, but the error message was in the sample code, so I'm not sure that's the real problem.

I've hit a little snag with UD_Tables, and I'm not sure the best way to recover.

I'm in a prototype database for a rather large client (implementation in progress).  Early in the design, we added a number of UD tables with the fields they wanted.  In addition to the standard business objects (e.g. CsName_Demo), we created a couple of custom ones.

As the prototype evolved, we discovered some of the fields weren't needed anymore.  Our normal MO for removing fields (bad habit, I know) is to remove them from Define Tables, then touch all the windows based on those tables, which cleans up the orphaned fields.  This time, we got a PK violation on UD_WindowFields.  Apparently, iMIS now only deletes rows from UD_WindowFields if they exist in UD_Field.  I cleaned up the orphaned fields through SQL and the windows worked OK.  That problem is solved, and desktop iMIS is (mostly) happy.

Is there any formal documentation on the AsiMembershipProvider and AsiRoleProvider?  I see some hit and miss troubleshooting in these posts but it would be nice to have some framework to start with. 

Is it just me, or are all the "business object" named things starting to become confusing? Here's the ones I can count:

• The original COM-based iBO
• iBO for .NET
• The core Business Objects which make up iMIS
• Business Object Builder, Business Object Architect, Business Object Designer, or whatever else it becomes
• Stephen Moseley's iBO Wrapper
• The Active Matter iBO Wrapper

Over the last 18 months or so as we have deployed the iMIS .NET server at clients and then tried to roll out components like IQA, etc to certain users, we (sorry, I wiped out the authors name accidentally) have experienced a variety of environment-related problems to which we have employed a variety of environment-related solutions. I was hoping that somewhere there existed or we could create (here perhaps) a definitive list of things to investigate / try when the rather inexpressive iMIS .NET error page pops up.

So, Stacey and I where chasing down this bug where when you added a PackageItem to a SourceCode's Package, only the first got added. Well... Until someone came back to the page and found that they had been added, they just never showed up in the list. It reaked of disconnected data caching issues.

Turns out, the issue was adding a PackageItem object that points to a Supplement Object that did not exist in the container. Once the SourceCode.GetSupplements() method was called it (correctly) set the ChildLoaded for Supplements to true, so subsequent calls to the Method would never check the DB for the underlying Supplement Object, and wouldn't hit the db to find it (since ChildLoaded was set to true for supplements), but it would add the PackageItem object since that only needed the key. In other words,

#1 SourceCode.GetPackageItems();
#2 SourceCode.AddPackageItem(key);
#3 SourceCode.GetPackageItems();

#3 DID NOT end up returning the PackageItem added on #2.