If you have to migrate InfoPath forms to a MOSS site, you should know about a new default view called Relink Documents. This view allows you to select migrated (submitted) forms and to relink them to the template in the new site. This view is automatically created when you publish and InfoPath form to a MOSS site.
Why do you need to do this? Submitted InfoPath forms contain XML, which contains the path of the XSN template that the forms uses to load. When you migrate forms from one site to the other, the XML will point to the old location. The Relink Documents feature allows you to select submitted forms and change them to reflect the new location path.
I'm sure you've come across a description or comments (multiple line of text) field in a task or issue list that goes blank when you go to edit it - the previous text entry is added as history/version. The setting for this can be turned on or off by going to the column settings and changing the "Append Changes to Existing Text"
In order to enable this feature, you must enable versioning. If you have it enabled and want to disable it be very cautious as you will lose all the previous history entries.
Hello, and welcome to my Mastering SharePoint blog! In this blog I will be sharing best practices, tips, how to's and other information for others members to read and hopefully learn from my experiences. Stay tuned....
A SharePoint colleague asked me how was I planning to address general site navigation, mainly the quick launch menu (menu bar located on the left side of a SharePoint site) to better organize the content at a departmental site level.
The issue, in his case, is that he is migrating from SharePoint v.2 to MOSS and is using a custom web part (in the old version) that allows collapsing and expanding the quick launch menu items. Some of the sites have a great amount of lists and libraries, so he's looking for a "flexible and compelling solution for navigation/menus" without having to re-architect the content of each site.
I could not really offer him a solution that, in my opinion, fits the "flexible and compelling" requirement. My experience with webparts that replace the quick launch menu are everything but flexible and typically require a person with some coding or scripting experience to create and maintain. I would also think that by customizing the launch menu, you would lose the security properties (not sure but feel free to comment on this) that come with MOSS.
The only advice I could offer him was to take this as an opportunity to work with each department/site administrator to plan for a new site navigation. In my case, I'm moving to a centralized model (true departmental sites, as opposed to everything under the root), so it's almost a requirement, which I welcome with open arms.
So... here is my plan (in a nutshell):
First and foremost, establish site owners and meet with each individually to take a look at their content. I know this seems like a no-brainer, but I'm amazed how many companies do not have defined roles for SharePoint sites.
Come up with site taxonomy. I'm adding to this blog a screenshot of our Maintenance department home page. This is not the most technical group, yet the biggest users of SharePoint. For this particular group, I wanted to make things very simple to access so we created topics. I created easy graphical shortcuts on the home page for each topic (see attached), which are linked to a corresponding "topic" page that has relevant content - we are using audiences to determine relevance. An entry to each topic page has been added to the quick launch menu. Links to lists and libraries (filtered by topic) are added to each topic page and security is applied to the list or library.
This is still a proof of concept. As I work with the content, I would have a better idea of how this will work for my users.
I welcome any comments, ideas or suggestions. I would like to learn how other users have approached navigation for their sites and what they are doing with the Quick Launch Menu.