This evening I ran into a profile synchronisation issue, where fields available in the User Information List were showing outdated personal information for each account, even when the equivalent field on the user profile had been updated. A field in the User Profiles was previously mapped to a field in Active Directory, and successfully pulled the corresponding data from AD during profile imports.
I wanted to allow the field to be edited in SharePoint, so AD mapping for this field was then removed. Data that was previously pulled from AD remained in the field, and at this point was in sync with data in User Information Lists accross the site collection. After making changes to the information via the My Profile area on the MySite Host, the changes were not reflected in User Information Lists.
Both full and incremental profile imports had run after the changes were made, but this didn't seem to have any effect on User Information Lists. I also used the sync operation in stsadm to force synchronisation of the User Information List (Both Profile Synchronization & Quick Profile Synchronization jobs), but this also had no effect. I also thought that the issue may have been due to the fact that this environment is used only for development purposes, and has had a small number of local service accounts as well as accounts imported from AD over time, some of which no longer exist. I tested this by modifying profile information for both a local and AD account, then forced a profile sync using stsadm. I was able to update information in the “My Profile” for both accounts, but neither of the changes were applied to User Information Lists after the sync jobs were completed.
After running the "stsadm -o sync -listolddatabases <num days>" command, I found that there were two databases with out of date sync information. I then ran the "stsadm -o sync -deleteolddatabases <num days>" command to remove the outdated sync information. The article Syncing WSS and MOSS User profile properties with Active Directory by Christian Dam provided me with information about User Profile Synchronisation, as well as the stsadm sync operation, which assisted with the process.
Once the old sync information databases were removed, I then retried forcing the sync operation for both the Profile Sync. & Quick profile Sync. Jobs. After checking that the Timer Job Status for the sync jobs had completed successfully via Central Administration, I then compared the information in User Information Lists on the site, which had also been successfully updated.
Other Related Resources:
Thursday, August 26, 2010
Thursday, August 19, 2010
Set SharePoint List Form Web Part field values using JavaScript when Creating New Item
How to set values of form fields generated by the SharePoint List Form Web Part when adding a new item to the list using JavaScript.
Using a custom metadata field in a SharePoint list to set categorisation & filter criteria that is later used by List and Data View Web Parts to arrange & filter content for specific audiences. Depending on the audience that a user is in, I wish to set alternate default values for specific fields rendered by the List Form Web Part.
In most cases, a custom multiple choice field in the list will be set to a value which corresponds to the current user’s audience, but will sometimes need to be manually adjusted. To improve the experience for end users, the appropriate checkbox option from the multiple choice field that corresponds to the current user’s audience will be selected when the form loads, and the default value for the field un-checked if required.
The custom field is used in multiple content types across the primary site collection. I found that when the field is included in a form rendered by the List View Web Part for a particular list, the HTML element name and id is not the equal to the same field rendered by a List Form Web Part on another list. For this reason, I included the javascript on the NewForm.aspx page only on the list i wish to implement the feature using a Content Editor Web Part (CEWP).
A separate CEWP containing the JavaScript for each audience was added to the page under the List View Web Part, then targeted to the corresponding audience.
The JavaScript used to update the field values is quite simple. As the field i wish to update is a multiple choice field (check boxes), I needed two lines of code in the script; the first unsellects the original default value for the field (set via the column settings), then selects the checkbox option that corresponds to the current user’s audience. As all CEWPs are targeted to each audience, only one should display and execute the JavaScript for each user. If a user is a member of more than one audience, the value set by the bottom most CEWP will be applied to the field rendered by the List Form Web Part.
Depending on the type of field being updated, you will need to update the JavaScript to set the field value with the appropriate data type and data. The steps below apply to a multiple choice field displayed as check boxes.
<script type="text/javascript" language="javascript" >
<!--
document.getElementById('checkbox default value id').checked = "";
document.getElementById('checkbox required value id').checked = "checked";
//-->
</script>
1. To find the Id of the fields that are being updated, view the source of the NewForm.aspx page and search for the internal name for the field. The field will be directly after a html comment containing information about the field:
<!--
2. Once you have found the position in the source containing the form input you with to update, first copy the id of the checkbox field that is selected by default.
3. In the first line of the above JavaScript, replace the text 'checkbox default value id' with the required Id of the form element.
4. Repeat step 2 to obtain the Id of the check box option you wish to select.
5. Replace (in the second line of the JS) the text 'checkbox required value id' with the required Id.
When the page loads, the CEWP corresponding to the current user’s audience will be displayed, resulting in the JavaScript updating the field values/selections in the above form generated by the List Form Web Part. The checkbox field specified in the second line of JavaScript will be selected, and the original default option unchecked.
Using a custom metadata field in a SharePoint list to set categorisation & filter criteria that is later used by List and Data View Web Parts to arrange & filter content for specific audiences. Depending on the audience that a user is in, I wish to set alternate default values for specific fields rendered by the List Form Web Part.
In most cases, a custom multiple choice field in the list will be set to a value which corresponds to the current user’s audience, but will sometimes need to be manually adjusted. To improve the experience for end users, the appropriate checkbox option from the multiple choice field that corresponds to the current user’s audience will be selected when the form loads, and the default value for the field un-checked if required.
The custom field is used in multiple content types across the primary site collection. I found that when the field is included in a form rendered by the List View Web Part for a particular list, the HTML element name and id is not the equal to the same field rendered by a List Form Web Part on another list. For this reason, I included the javascript on the NewForm.aspx page only on the list i wish to implement the feature using a Content Editor Web Part (CEWP).
A separate CEWP containing the JavaScript for each audience was added to the page under the List View Web Part, then targeted to the corresponding audience.
The JavaScript used to update the field values is quite simple. As the field i wish to update is a multiple choice field (check boxes), I needed two lines of code in the script; the first unsellects the original default value for the field (set via the column settings), then selects the checkbox option that corresponds to the current user’s audience. As all CEWPs are targeted to each audience, only one should display and execute the JavaScript for each user. If a user is a member of more than one audience, the value set by the bottom most CEWP will be applied to the field rendered by the List Form Web Part.
Depending on the type of field being updated, you will need to update the JavaScript to set the field value with the appropriate data type and data. The steps below apply to a multiple choice field displayed as check boxes.
<script type="text/javascript" language="javascript" >
<!--
document.getElementById('checkbox default value id').checked = "";
document.getElementById('checkbox required value id').checked = "checked";
//-->
</script>
1. To find the Id of the fields that are being updated, view the source of the NewForm.aspx page and search for the internal name for the field. The field will be directly after a html comment containing information about the field:
<!--
FieldName="fieldname"
FieldType="SPFieldMultiChoice"
-->2. Once you have found the position in the source containing the form input you with to update, first copy the id of the checkbox field that is selected by default.
3. In the first line of the above JavaScript, replace the text 'checkbox default value id' with the required Id of the form element.
4. Repeat step 2 to obtain the Id of the check box option you wish to select.
5. Replace (in the second line of the JS) the text 'checkbox required value id' with the required Id.
When the page loads, the CEWP corresponding to the current user’s audience will be displayed, resulting in the JavaScript updating the field values/selections in the above form generated by the List Form Web Part. The checkbox field specified in the second line of JavaScript will be selected, and the original default option unchecked.
Related:
- Split List View web part labels (javascript) - The following is a javascript function created to split long questions / column titles on a SharePoint survey or list when editing (EditForm.aspx / DispForm.aspx).
Wednesday, August 18, 2010
Useful Tip: Add a link to Create a New Document From a Content Type Template
I found a blog post by Andy Burns that explains how to find and use the javascript from the 'New' button on a Document Library with managed content types to add a link to any page which will open a new document from the template.
As the "add new document" link on the summary toolbar of a List or Data View Web Part links to the Upload page of the document library, i used the javascript from the new button instead to create a link that opens a new blank document from the content type template associated with the document library. This meant that the default save location for the document was set to the document library.
Andy's post explains how to incorporate the javascript behind the 'New' button into a link on a different page.
The issue that I was attempting to resolve is that I wanted to use the link in client applications outisde of SharePoint. this meant that I couldn't use javascript, as the function called was not available to the application.
My solution was to add the javascript to the head setion of a separate page to a function which is called by the settimeout() method after a few seconds. Once the function is called and the blank document loaded, the script redirected to the default view of the document library.
I used the timeout method as the script was not working properly if the page had not fully loaded, as well as to display a brief message to the user informing them of the process before redirecting to the document library. Redirecting to the document library also prevents an infinant loop if you press "Cancel" if asked to confirm opening the blank document, as the page is reloaded when the Cancel button is pressed.
Javascript:
function newDoc()
{
'create a new document from a specific content type template
createNewDocumentWithProgID('http:\u002f\u002fserver\u002fsites\u002fSales\u002fDocuments\u002fForms\u002fSales Order Form\u002fnew.xlsx', 'http:\u002f\u002fserver\u002fsites\u002fSales\u002fDocuments\u002fForms\u002fSales Order Form', 'SharePoint.OpenDocuments', false);
're-direct to the document library (default view)
window.location = 'http://server/sites/Sales/Documents/';
}
setTimeout ( "newDoc();", 1000 );
View Andy's post: Add a ‘Create New Document’ link to a page
As the "add new document" link on the summary toolbar of a List or Data View Web Part links to the Upload page of the document library, i used the javascript from the new button instead to create a link that opens a new blank document from the content type template associated with the document library. This meant that the default save location for the document was set to the document library.
Andy's post explains how to incorporate the javascript behind the 'New' button into a link on a different page.
The issue that I was attempting to resolve is that I wanted to use the link in client applications outisde of SharePoint. this meant that I couldn't use javascript, as the function called was not available to the application.
My solution was to add the javascript to the head setion of a separate page to a function which is called by the settimeout() method after a few seconds. Once the function is called and the blank document loaded, the script redirected to the default view of the document library.
I used the timeout method as the script was not working properly if the page had not fully loaded, as well as to display a brief message to the user informing them of the process before redirecting to the document library. Redirecting to the document library also prevents an infinant loop if you press "Cancel" if asked to confirm opening the blank document, as the page is reloaded when the Cancel button is pressed.
Javascript:
function newDoc()
{
'create a new document from a specific content type template
createNewDocumentWithProgID('http:\u002f\u002fserver\u002fsites\u002fSales\u002fDocuments\u002fForms\u002fSales Order Form\u002fnew.xlsx', 'http:\u002f\u002fserver\u002fsites\u002fSales\u002fDocuments\u002fForms\u002fSales Order Form', 'SharePoint.OpenDocuments', false);
're-direct to the document library (default view)
window.location = 'http://server/sites/Sales/Documents/';
}
setTimeout ( "newDoc();", 1000 );
View Andy's post: Add a ‘Create New Document’ link to a page
Monday, August 16, 2010
InfoPath SharePoint Development
SharePoint News & Development Resources
DevSharePoint.com provides the latest SharePoint news and resources. Stay up to date with SharePoint 2010, MOSS 2007, WSS, SharePoint Designer (2007/2010), InfoPath.
InfoPath & SharePoint Development Tutorials, Resources & How To's
InfoPathSharePoint.net provides the latest InfoPath development tutorials, InfoPath Form Services administration tips, tricks and how to's. InfoPath SharePoint Integration: Integrate InfoPath Forms with SharePoint lists, libraries & workflow.
SharePoint & InfoPath News & Resources
SharePoint Administration, Development, Design & Customization Resources from around the internet. SharePoint & InfoPath News. InfoPath SharePoint Integration. InfoPath Form Template Design. InfoPath Form layouts, design tips & techniques.
DevSharePoint.com provides the latest SharePoint news and resources. Stay up to date with SharePoint 2010, MOSS 2007, WSS, SharePoint Designer (2007/2010), InfoPath.
InfoPath & SharePoint Development Tutorials, Resources & How To's
InfoPathSharePoint.net provides the latest InfoPath development tutorials, InfoPath Form Services administration tips, tricks and how to's. InfoPath SharePoint Integration: Integrate InfoPath Forms with SharePoint lists, libraries & workflow.
SharePoint & InfoPath News & Resources
SharePoint Administration, Development, Design & Customization Resources from around the internet. SharePoint & InfoPath News. InfoPath SharePoint Integration. InfoPath Form Template Design. InfoPath Form layouts, design tips & techniques.
Sunday, August 15, 2010
Metadata Property Mappings - Managed Property not populating with data
Managed Property not populating with data
I was playing around with search scopes and result page XSL templates in order to develop a search solution that incorporates custom fields from a content type used on multiple site collections. Content types containing custom columns that were to be searched across, as well as displayed in the search results.
The same content type has been reused multiple times across the primary site collection, and has also been deployed and used multiple time in other site collections. When configuring managed metadata property mappings for the custom fields, I was able to map each field to a managed property by searching for the field name.
I was then able to create an advanced search page the included the custom properties. When incorporating the additional managed properties into the search results, I found that only items from the original (primary) site collection would have data associated with the custom mappings.
The content type had been deployed to each site collection by deploying and enabling an InfoPath Form Service solution. The content type created once enabled was then associated with the form library from each site collection. I found that the internal column names from the content types on all site collections except for the primary site collection were set in the format of an Id, and not the text representation for column names the original content type.
To allow the managed properties to contain data from a particular column across each site collection, I needed to do one of the two things:
1. Remove and re-create the column on the site collections where the column names were set as Ids. This resulted in the column names reverting to the same text name of the equivalent column on the primary site collection. The search crawler then maps data from the column on each site collection.
Or:
2. Update the managed properties so that each instance of the column in each site collection is mapped to the Managed Property in Central Administration. To do this, I needed to obtain the internal column names, which in this case were in the same format as a list or column id in SharePoint. When finding columns from the SharePoint farm to map to the managed property, searching for part of the column id resulted in the column being found. After adding each instance of the columns from all site collections using the column ids, I then selected the option to “Include values from a single crawled property based on the order specified”. This results in the managed property being populated with data from one of the mapped columns only, which will be the first one that contains data in the order specified.
After performing a full crawl of all site collections in the farm, the search results successfully incorporated the custom managed properties. The advanced search now searched across all site collections to find items using values in the custom fields.
I was playing around with search scopes and result page XSL templates in order to develop a search solution that incorporates custom fields from a content type used on multiple site collections. Content types containing custom columns that were to be searched across, as well as displayed in the search results.
The same content type has been reused multiple times across the primary site collection, and has also been deployed and used multiple time in other site collections. When configuring managed metadata property mappings for the custom fields, I was able to map each field to a managed property by searching for the field name.
I was then able to create an advanced search page the included the custom properties. When incorporating the additional managed properties into the search results, I found that only items from the original (primary) site collection would have data associated with the custom mappings.
The content type had been deployed to each site collection by deploying and enabling an InfoPath Form Service solution. The content type created once enabled was then associated with the form library from each site collection. I found that the internal column names from the content types on all site collections except for the primary site collection were set in the format of an Id, and not the text representation for column names the original content type.
To allow the managed properties to contain data from a particular column across each site collection, I needed to do one of the two things:
1. Remove and re-create the column on the site collections where the column names were set as Ids. This resulted in the column names reverting to the same text name of the equivalent column on the primary site collection. The search crawler then maps data from the column on each site collection.
Or:
2. Update the managed properties so that each instance of the column in each site collection is mapped to the Managed Property in Central Administration. To do this, I needed to obtain the internal column names, which in this case were in the same format as a list or column id in SharePoint. When finding columns from the SharePoint farm to map to the managed property, searching for part of the column id resulted in the column being found. After adding each instance of the columns from all site collections using the column ids, I then selected the option to “Include values from a single crawled property based on the order specified”. This results in the managed property being populated with data from one of the mapped columns only, which will be the first one that contains data in the order specified.
After performing a full crawl of all site collections in the farm, the search results successfully incorporated the custom managed properties. The advanced search now searched across all site collections to find items using values in the custom fields.
Tuesday, August 10, 2010
Metadata not saving after editing properties - Document Metadata Error
Metadata Error: Metadata not saving on item in Document Library after editing Properties
Scenario:
I came accross an issue in a Document library where i was unable to update the document metadata properties using the SharePoint interface. The Edit Item page worked fine, and I was able to set the metadata to the values i required, but after pressing ok to save the metadata the new values weren’t being saved into SharePoint (reverting back to the previous value).
The issue was on multiple documents, but not specific to a folder within the library or dependent on certain metadata properties. The majority of documents in the library work fine when applying changes to metadata.
After troubleshooting the issue a little, I found that I was able to update the metadata when editing the document using Office 2007. After saving the document (stored in SharePoint), the metadata would be applied as expected. I was also able to replicate the issue in a separate document library, where documents saved in Office 2007 format were not able to have the metadata applied using the SharePoint browser interface.
Searching the Internet for information about the issue didn’t help a lot in the end, but gave me a few things to try. Issues others were having were possibly related to managed content types resulting in multiple columns being referenced in a document, and the patch level of the SharePoint environment. Some users with SP1 or later applied weren’t able to replicate the issue. See the following for more info:
- Metadata from Word 2007 Document Information Panel not Populating Columns in SharePoint Document Libraries and vice-a-versa
- Metadata not saved when uploading Doc and Docx documents
Possible Cause(s)
Office 2007 Document in SharePoint Library with 2003 Compatible template
Service Pack - Patch Level
Managed Content Types:
- Corrupt Document Template associated with Content Type
- Duplicate Columns (1 associated with library, one with content type)
Resolution / Workaround:
I was able to save the metadata properties to a document by updating the metadata using Word 2007 (haven’t tested using 2003). To allow document metadata properties to be saved using the SharePoint interface, my workaround was to convert the document to an Office 2003 compatible document (from .docx back to .doc).
Subscribe to:
Posts (Atom)
Posts
