The problem:
A workflow assigned me a task. I opened the task email in Outlook 2010 and then pushed the "Open This Task" button on the ribbon. All I got was a flickering progress box. The task was never opened and it took me quite a while to get rid of the flickering progress box.
The solution:
This seems like a security issue (and could have been handled more gracefully by Outlook.) While normally I don't advocate editing system files on the hive, this is the case when it is necessary. I opened the 14\LAYOUTS\FormsServer.aspx and added the following line right after the <body> tag:
<SharePoint:FormDigest runat="server" />
This creates a security validation for the FormsServer.aspx page and thus gets rid of the annoying flickering issue.
Some interesting problems I face day-to-day as a SharePoint 2010 developer.
Friday, February 24, 2012
Friday, February 17, 2012
Threaded View in Discussion Boards
The problem:
Our customer created a discussion board and a custom threaded view for this list and made this new threaded view a default one. Now he is no longer able to access this list. When he tries to do so, he gets a nasty and cryptic "Attempted to use an object that has ceased to exist. (Exception from HRESULT: 0x80030102 (STG_E_REVERTED))" error message.
The solution:
The root cause of this is the misconfigured threaded view. Unfortunately, Microsoft made it too easy to make an error here. The threaded view (and the flat view, too, for that matter) do not work on top-level folders, therefore the only proper way to configure folders for the threaded view or the flat view is this:
To fix the problem I mentioned, the view that is not working must be removed and re-created - to get to the list settings, follow the "Content and Structure" link in the Site Administration, and then follow the "Edit Properties" link in the hovering menu.
Our customer created a discussion board and a custom threaded view for this list and made this new threaded view a default one. Now he is no longer able to access this list. When he tries to do so, he gets a nasty and cryptic "Attempted to use an object that has ceased to exist. (Exception from HRESULT: 0x80030102 (STG_E_REVERTED))" error message.
The solution:
The root cause of this is the misconfigured threaded view. Unfortunately, Microsoft made it too easy to make an error here. The threaded view (and the flat view, too, for that matter) do not work on top-level folders, therefore the only proper way to configure folders for the threaded view or the flat view is this:
To fix the problem I mentioned, the view that is not working must be removed and re-created - to get to the list settings, follow the "Content and Structure" link in the Site Administration, and then follow the "Edit Properties" link in the hovering menu.
Wednesday, February 15, 2012
Search Service Application
The problem:
I have a search service application in my farm, My only content source contains several claims-aware SSL Web applications. Unfortunately, for some reason, the gatherer was not able to crawl them, throwing a 404 status, for no apparent reason. Deleting and re-creating the search service application did not help matters at all. The ULS logs did not show anything unusual, and neither did the IIS logs.
The solution:
Actually, it was more like a workaround that my co-worker and I invented. He has another SharePoint farm on the same domain. We made our farms trust each other, and then I made my farm consume his search service application. See http://technet.microsoft.com/en-us/library/ee704558.aspx on how exactly to do this. Then, I created my own content source and added my own crawl rule and registered my own custom security trimmer. After all these manipulations, the search worked!
I have a search service application in my farm, My only content source contains several claims-aware SSL Web applications. Unfortunately, for some reason, the gatherer was not able to crawl them, throwing a 404 status, for no apparent reason. Deleting and re-creating the search service application did not help matters at all. The ULS logs did not show anything unusual, and neither did the IIS logs.
The solution:
Actually, it was more like a workaround that my co-worker and I invented. He has another SharePoint farm on the same domain. We made our farms trust each other, and then I made my farm consume his search service application. See http://technet.microsoft.com/en-us/library/ee704558.aspx on how exactly to do this. Then, I created my own content source and added my own crawl rule and registered my own custom security trimmer. After all these manipulations, the search worked!
Subscribe to:
Posts (Atom)