Posted by: doug | January 3, 2012

.NET Membership Provider – Delete User Error

Error: The DELETE statement conflicted with the REFERENCE constraint “FK__aspnet_Me__UserI__15502E78″. The conflict occurred in database “YourDBName”, table “dbo.aspnet_Membership”, column ‘UserId’.

Took me a while to find a solution to this across multiple sites and options as the error and possible solutions were rather misleading.  Turns out, at least in my case, it was a problem with permissions on the membership database.  The user I’m using to connect had access to view the membership details within the database itself, but as part of the aspnet_Users_DeleteUser stored procedure it selects from the sysobjects table.  The membership connection user apparently did not have sufficient rights to do that select so the overall delete failed.

The fix for me was to add the user to the aspnet_Membership_FullAccess role for the membership database.

I found this elsewhere in various forums and comments but not very concisely.  Basically it comes down to, you can’t nest block elements in a P tag.  If you do, you can’t edit the innerHTML of that block element.

Take the block element out of the P tag and you should be set.  In my case this was in using Googiespell, a great free spellchecker for your site.

Posted by: doug | January 3, 2012

MOSS 2007 Presence Awareness Problem

I was just trying to add presence awareness links to a custom people search result page usingthese excellent instructions on how to create an employee directory web part. My only problem was that the presence icon was only showing up for the first result on the page.

I found that articles on how to add the presence information are all over the place and all pretty consistent, but only one gave me the key I needed. From Jan Tielens’ article onShowing Presence Information In SharePoint Web Parts, “Make sure your put span tags around image and the text…”. Yep, that fixed it. No one else bothered to mention that little tidbit. Thanks much Jan!

Posted by: doug | January 3, 2012

MOSS 2007 MySite Organization Hierarchy

If you’ve used MOSS 2007 MySite’s, then you’re likely familiar with the Organization Hierarchy web part on the main profile page that displays your peers and manager.  Don’t know if anyone else would ever need/want to do this, but in our organization we were in need of not displaying the organization hierarchy of a particular department.

I’ve been unable to find any documentation on this feature, asside from it being powered by the manager listed for each employee in active directory.  When our need to exclude this department first came up, I just stopped importing Manager from AD so this would not be populated.  If you want to completely remove this web part’s information, then read no further as un-mapping manager from AD to the Manager profile property will do the trick for you.   In our case, there’s since been movement to start using MySites more and so we wanted to be able to display this information, but again, exclude this one department.

I was finally able to track down the key, the stored procedure in your Shared Services database for the site called profile_GetUserReportToData.   This is where the hierarchy information comes from.   So now all I had to do was modify the queries in this stored procedure to exclude anyone from the department in question.   Just add to the end of the WHERE clauses:

AND NOT V.RecordID IN (SELECT V2.RecordID FROM UserProfileValue V2
WHERE V2.RecordID = V.RecordID AND V2.PropertyID = 14
AND CAST(V2.PropertyVal as nvarchar(150)) LIKE ‘DeptName%’)

Your PropertyID may be something other than 14, so just check the UserProfileValue table first to see which one has the department information in it.  And DeptName would be the name of the department you’re excluding.

Disclaimer: Making changes to your SharePoint database directly could be dangerous to the stability of your install and be undone by future upgrades. Do this at your own risk.

Posted by: doug | January 3, 2012

MOSS 2007 Reserved Profile Properties

With MOSS 2007 User Profile Properties, in most cases you’re allowed to set Policy Settings as to whether the property is required, who can see it and whether or not the user can change this policy.  However there are apparently some of these properties that are considered reserved by SharePoint and the options to change the policy settings are grayed out.   But where there’s a will (and a lack of fear from poking at sharepoint databases), there’s a way to adjust these settings.

They key to this is in the UserPrivacyPolicy table in your Shared Services database.  First you must find the PropertyID for the property you want to unlock in the PropertyList table.  Once you have this, find the record for this property and set the value of theIsPolicyOverridable field to True.  Now when you edit the property settings via the normal central administration web interface, you should be able to override the default settings.

Disclaimer: Making changes to your SharePoint database directly could be dangerous to the stability of your install and be undone by future upgrades. Do this at your own risk.

Posted by: doug | January 3, 2012

MOSS 2007 Document Permission Issues

If you have worked with SharePoint, you are probably aware of the fine grained permissions that can be set anywhere from the site level down to the individual document level.  You have probably run into the usual problems associated with assigning permissions, inheritance and problems with breaking inheritance.  But occassionally even when the permissions are set correctly for a given user, they will still get a permission denied error when trying to access a document or form.

I have found the answer usually has to do with the way windows caches files it opens from SharePoint.   And here are my two solutions.

In the case of InfoPath forms, either saved in a form library or being emailed to users, part of the key is to use unique file names.  If you call every form, Form.xml, windows seems to cache the first one you open which causes problems with subsequent versions you try to open with the same name.  Typically I tell users to use a formula to create the file name.  If there’s a field in the form that will typically be different per form, then append that.  If not, just append the current date and time.

If that does not work, or it is some other kind of file, then the handy Disk Cleanup tool (apparently little known based on the blank stares I get when I mention it, even to tech support types) is probably going to be your best friend.  Here’s what you do:

  1. Click on Start -> Programs -> Accessories -> System Tools -> Disk Cleanup
  2. It will run through a check of files on your computer.
  3. When done, select Temporary Internet Files, Temporary Files and if you have it, Microsoft Office Temporary Files
  4. Click OK, then Yes to confirm you wish to perform these actions.
  5. Once it is done, try the document again.
Posted by: doug | January 3, 2012

jQuery wrap(html) not working – appendChild bug

Today I ran into a problem where jQuery’s wrap function wasn’t working. It took me a while to figure out there even was a problem as it turns out it’s browser specific. One guess, which browser had the problem. IE 7. I’d already upgraded to IE 8 which apparently fixed the appendChild bug.

At first in IE I only got a generic line blah error.  But with the help of a co-worker who still had IE 7 installed, we were able to determine that the error was happening when jQuery was trying to append my wrapped content using .appendChild.   Then came the requisite Google search which led me to the IE 7 appendChild bug.

This apparently only happens when you try and use appendChild on an object inside a table, which was the case for what I was trying to wrap.   In my case I was able to work around it by doing the wrapping manually.  So good for IE 8 for fixing the bug, now let’s just hope people upgrade.

Posted by: doug | January 3, 2012

jQuery/IE XML Error

Another odd jQuery issue to report (though not really jQuery’s fault).  We just launched a new site with a Google suggest-esk drop down.  The suggest list is populated via an XML feed from our CRM.  After much pre-launch testing, we got a couple post-launch bug reports of a javascript error and the drop down not working.  Using the un-minified version of jQuery I was able to track it down to an error being returned from the isXML function it uses.

As with many quirky errors, this one was only happening in IE and only on two computers.  Based on where the error was I assumed it had to do with how the XML was being handled.  To make a long story short, the problem had to do with my using Microsoft.XMLDOM to create the XML document for jQuery to process.  Apparently on these two computers, this version did not properly format the XML.  By instead specifying to use Msxml2.DOMDocument.4.0, the error went away

Posted by: doug | January 3, 2012

InfoPath Form – Not Updating / Cached

If you publish InfoPath forms to SharePoint, or this may even happen if you put them in other network locations, you may find that when making an update to the form, some users continue to see the old version. I recently tracked this down as being caused by InfoPath caching a version of the form on the users computer.

In theory, InfoPath is supposed to prompt you to let you know that the server version has changed and allows you to update your local cached version.  In reality, this seems to either not always happen or users aren’t understanding and therefore not updating their local cache.  The fix seems to be to clear that local cache to force it to open the latest version from the server.  Easiest way I found is to delete any files/folders in this directory:

C:\Documents and Settings\{UserName}\Local Settings\Application Data\Microsoft\InfoPath\FormCache2\

This will remove all cached forms.  If that’s over kill for you, you can go through the directories there and find the one for the form you’re having a problem with and delete just that one.

Posted by: doug | January 3, 2012

Mailto Link Limits / SharePoint E-mail Users Option

We had a user not able to use the E-mail Users option on a SharePoint group.  When selecting all the users to email she would get the error, “Could not perform this operation because the default mail client is not properly installed”.  Rather a misleading error, as her mail client was installed just fine.

The problem is that this option in SharePoint uses javascript to create a mailto: link with the selected addresses.  As I finally found on the Google Machine, Outlook and other email clients impose limits on the length of a mailto string.  Understandable as a security measure, but annoying in this case.

So the fix?  Select fewer people to email to.  In this user’s case, she’ll be better off managing her email group in Outlook vs trying to use SharePoint.

« Newer Posts - Older Posts »

Categories

Follow

Get every new post delivered to your Inbox.