Showing posts with label Sharepoint Errors. Show all posts
Showing posts with label Sharepoint Errors. Show all posts

Monday, May 3, 2010

The BDC, Required Metadata, and the Word2007 Properties Panel = FAIL

Word 2007 has some nice integration features with Sharepoint.  One of them is the implementation of a "Server Properties" panel from with the client.  Its intended purpose is to allow the user to edit both the document's content and metadat from within the same interface.  It works flawlessly with simple metadata.  However, when you introduce a metadata field that taps into the business data catalog (BDC), things go horribly, horribly wrong.

Ideally, your document has a field that exposes a connection to the BDC and then tries to autopopulate other fields based on that connection.  In the Sharepoint 'Properties' page, these autopoulated fields are editable.  However, in the Word2007 client, these fileds are grayed out, waiting for data from the BDC.  You cannot edit these fields.  This becomes problematice if the Primary Key field for the BDC metadata is required.  The Word2007 client interprets not only the main field as required, but all the fields that this connector autopopulates.  What if your database record for this primary key is not fully filled out?  What if its missing one piece of data?  That data cannot be autopoulated into the metadata field (which is implicitly required in Word2007).  As a result, when you try to save and check in the document, Word throws an error saying that the required meatdata is not filled out.  You are stuck!  You can't leave any field blank, but you also can't fill them out due to the fact that they're autopopulated. 

At this point you have one of 4 options:
  • Uncheck the 'Required' property for the Primary Key BDC metadata
  • Upload, but don't check in the document.  Then go into the Sharepoint GUI, fill out the required properties, and check in.
  • Check in the document using Word 2003 or earlier.
  • Fill out all the data for that BDC record in the source database.
None of these workarounds are good from a usability standpoint.  If anyone has a better workaround for this, let me know.

"Unknown user profile error..."

This was a particularly devilish problem that came to light last year.  Our team's information architect was updating his MySite in Sharepoint when he got this error.  He had no idea why it suddenly popped up.  He had been uploading a new picture to his profile when the error occured. 
Ok, it doesn't like the picture file for some reason, I'll just delete it.
Nope, it still gave him the error even after deleting the picture.  Now every save to the profile, no matter how small, threw the error. 
Something must have changed in the environment thats broken the MySite collections.

Wrong answer again.  No changes or updates had been applied to production in that week.  So what is going on here?  The short answer is that there is a bug i how Sharepoint handles some configurations of the Profile field properties.  That's a pretty general answer, but I'll break it down step-by-step.

If a property for a field is configured in the following manner:


'User can override security policy' (YES),
AND
'Do not allow user to make changes to this field'
AND
There is text in the field.

...the profile will not save correctly. What can mask this condition is if there is no content in a that field.  You may have those properties set on the profile that will cause the error, but until the user populates the field with content, no error will be thrown.  It took me several iterations of careful troubleshooting to figure this one out.  You can mitigate these errors by unchecking the 'User can override security policy' property.  Logically, you can see how the two properties in question can conflict with each other.  If the 'security policy' is a property of the field, but you don't allow users to make changes to the field, and you choose to let user's override it....well, you see the loop we're in now?

In our case, we have information importing from a Domino database that populates these fields.  So our information architect was filling out his information in his Lotus Notes address book, and 'causing' errors in Sharepoint.  Hope this helps anyone with similar problems.