December | 2010 | Are you a user?

Archive for December, 2010

Dec

Can’t update record in datasheet view

Categories: SharePoint Errors

Here’s a simple one, but it underscores how important good error messages are.

You are in SharePoint 2010 on a task list and you are attempting to update the task status and other columns using the datasheet view. You get an error:

“An unexpected error has occurred. Changes to your data cannot be saved. For this error, you can retry or discard your changes.”

You are presented with the following dialog.

Not very helpful, huh?

No matter how many times you retry your changes, you get the same general error.

So you try to update the item using a standard SharePoint form and you receive an error with a little more meat.

“This item cannot be updated because it is locked as read-only.”

Now you are suddenly reminded that in-place records management is enabled!

You check the Compliance Details for the item and find that you declared it as a record before Christmas and that has put a read-only lock on the item.

You also find your memory is mush from the holidays. There is no solution for that.

Dec

Removing the view selector from a Sharepoint 2010 infopath form

By Russell Wright Leave a Comment

Categories: InfoPath

If you have created custom InfoPath forms for a list in SharePoint 2010 and you have custom views for each of the New, Edit and View forms, you might find the InfoPath view selector showing up when you don’t want it to. This could allow users to change to the Edit view on your New item form, for example.

To fix this, you can select the View Properties from the Page Design menu in InfoPath and uncheck the “Show on the View menu when filling out the form” option.

If all of your views have this unchecked, then the view selector will not appear on the SharePoint InfoPath form.

Dec

Conditional Formatting and date comparisons with SharePoint Designer 2010

By Russell Wright 22 Comments

Categories: SharePoint Customization and SharePoint Designer

So here’s a fun one that we at SharePoint Rx were struggling with the other day.

We were creating a dashboard using the DVWP in SharePoint Designer 2010 and had to perform some date comparisons to control the display of indicators. If you’ve used SPD in the past, you know that the goal is to NOT write code, but to use the “coding by clicking” capabilities of SPD and allow it to write the code (in this case XSL) to control your conditional formatting. Every time I use SPD for something like this, I always seem to run into a new problem, even though I know it should be a simple task.

“Am I the only one with this issue?” he asks.

Here’s the end goal…to display a status indicator for tasks to indicate whether they were completed on time, completed late, not complete and not late, and not complete and late. You can see the four icons I chose to indicate these statuses.

My “conditions” are as follows:

Status equals “completed” and Due Date >= Completed Date

Status equals “completed” and Due Date < Completed Date

Status not equals “completed” and Due Date >= [Current Date]

Status not equals “completed” and Due Date < [Current Date]

One of the issues you immediately experience is the comparison of date values. Using SPD, I did an “un-advanced” comparison in my condition statements and never got the correct results. SPD wrote some XSL like this (I broke it up so it’s a little easier to read):

<xsl:if test=”normalize-space($thisNode/@Status) = ‘Completed’

and

ddwrt:DateTimeTick(ddwrt:GenDisplayName(string($thisNode/@DueDate))) >=
normalize-space(@Completed_x0020_Date)” ddwrt:cf_explicit=”1″>
<img src=”_layouts/images/kpinormal-0.gif” width=”16″ height=”16″ />

</xsl:if>

So we have a “Due Date” that has been operated on by ddwrt:DateTimeTick (see if you can find any documentation on this function) and is returning the number of days from January 1, 1900 comparing to the “Completed Date” in the form “MM/DD/YYYY.” That doesn’t work!

Sidebar rant…Come on, Microsoft! The only documentation on the ddwrt namespace is from a non-MS person (Serge van den Oever ) and is from 2005…for SharePoint 2003?

So, let’s look at the “Advanced” condition criteria that does work.

We used the completely undocumented ddwrt:DateTimeTick function and applied it equally to both dates.

When performing the comparison with [Current Date], here’s what we did.

We were successful with using the $Today variable, but I’ve seen others who have also used ddwrt:Today.

Here are the criteria for all four conditions.

@Status = ‘Completed’ and ddwrt:DateTimeTick(ddwrt:GenDisplayName(string(@DueDate))) >= ddwrt:DateTimeTick(ddwrt:GenDisplayName(string(@Completed_x0020_Date)))

@Status = ‘Completed’ and ddwrt:DateTimeTick(ddwrt:GenDisplayName(string(@DueDate))) < ddwrt:DateTimeTick(ddwrt:GenDisplayName(string(@Completed_x0020_Date)))

$thisNode/@Status != ‘Completed’ and ddwrt:DateTimeTick(ddwrt:GenDisplayName(string($thisNode/@DueDate))) >= ddwrt:DateTimeTick(ddwrt:GenDisplayName(string($Today)))

$thisNode/@Status != ‘Completed’ and ddwrt:DateTimeTick(ddwrt:GenDisplayName(string($thisNode/@DueDate))) < ddwrt:DateTimeTick(ddwrt:GenDisplayName(string($Today)))

Now, I’d like to believe that features in SPD 2010 that were in SPD 2007 were all functioning correctly, but I seem to have lots of problems using the “All formatting visible” functionality. I found that each time I changed this I must

Save the page
Press F5 to refresh (sometimes more than once)

Not sure what that’s about or if it’s just one of my settings, but it sure is annoying.

Of course, the idea is that you want to make all your conditionally formatted elements visible so you can easily work on them.

FYI, if you want to determine which condition applies to which element, you can select the condition and you should notice a highlighting of the element to which the condition corresponds.

Keywords:

Conditional formatting

SharePoint Designer 2010

Date comparison

Data view web part

ddwrt namespace

Dec

Updating the Application Pool Account on a SharePoint 2010 Site

By Russell Wright 1 Comment

Categories: SharePoint Infrastructure

I was working on changing the security on a 2010 site to use domain accounts instead of local and built-in accounts. The problem I was having was that a non-administrative user couldn’t log into the SharePoint site, even though the user was a site collection administrator.

I created an app pool account to use (spDemoAppPool) and used SCA (SharePoint Central Administration) to register the account and assign the account to the application pool to replace the Network Service account.

After making this change, I ran the configuration wizard to have it fix the security on the app pool account. However, I found that it didn’t fix all the security. When looking at this Technet article, I found that the SQL security in the last two bullets was not correctly assigned.

http://technet.microsoft.com/en-us/library/cc678863.aspx#Section3

Other application pool accounts

The other application pool account must be a domain user account. This account must not be a member of the administrators group on any computer in the server farm.

The following machine-level permission is configured automatically: This account is a member of WSS_WPG.

The following SQL Server and database permissions are configured automatically:

This account is assigned to the db_owner role for the content databases.
This account is assigned to the db_owner role for search databases associated with the Web application.
This account must have read and write access to the associated service application database.
This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the farm configuration database.
This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the SharePoint_Admin content database.

If you use SQL Server Management Studio, you can find the SharePoint Config and Admin_content databases and look at the properties on the WSS_Content_Application_Pools database role.