Step 1: Download Adobe PDF IFilter 5.0 from the following Adobe Web site: http://www.adobe.com/support/downloads/detail.jsp?ftpID=1276
Step 2: Stop the IIS Admin service. To do this, follow these steps:
a. Click Start, point to Administrative Tools, and then click Services. b. Right-click IIS Admin Service, and then click Stop.
Step 3: Run the Adobe PDF IFilter 5.0 Setup program to install the filter on the server. (For MOSS 2007, install the PDF iFilter on the Index servers) After installing the iFilter, perform Steps 5, 6, and 7 on all the Web Front End servers in the farm.
Step 4: Register the Adobe PDF IFilter. To do this, follow these steps:
a. Click Start, and then click Run. b. In the Open box, type cmd, and then click OK. c. Switch to the folder that contains the Adobe PDF Filter 5.0 files. For example, switch to the following folder: Drive:\Program Files\Adobe\PDF IFilter 5.0 d. Type regsvr32.exe pdffilt.dll, and then press ENTER. e. If you receive a message that states that the operation was successful, click OK . f. Type exit, and then press ENTER to exit the command prompt.
Step 5: Copy the .gif file that you want to use for the icon to the following folder on the server, as appropriate for your situation: Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Images
Step 6: Edit the Docicon.xml file to include the .pdf extension. To do this, follow these steps:
a. Start Notepad, and then open the Docicon.xml file. The Docicon.xml file is located in one of the following folders on the server: Drive:\Program Files\Common Files\Microsoft Shared\Web server extensions\12\Template\Xml b. Add an entry for the .pdf extension. For example, add a line that is similar to the following to the Docicon.xml file, where NameofIconFile is the name of the .gif file: c. On the File menu, click Save, and then quit Notepad.
Step 7: Restart the server.
Step 8. Add the .pdf file type to the content index. To do this, follow these steps:
a. Connect to the portal site, and then click Site Settings. b. On the Site Settings page, click Configure search and indexing under Search Settings and Indexed Content. c. On the Configure Search and Indexing page, click Include file types under General Content Settings and Indexing Status. d. On the Specify File Types to Include page, click New File Type. e. On the Add File Type page, type pdf in the File extension box, and then click OK.
Step 9. Update the context indexes for portal content and for non-portal content. To do this, follow these steps:
a. On the Site Settings page of the portal site, click Configure search and indexing under Search Settings and Indexed Content. b. On the Configure search and indexing page, click Manage content indexes under Content Indexes. c. On the Manage Content Indexes page, click the down arrow next to the name of the index that you want to update, and then click Start Full Update.
The default view being used is called the "Summary View", which unfortunately, is not directly editable through the normal "Edit the current view" option in the webpart...or more to the point, is limited to what you can edit on it. The default columns being displayed in this view cannot be removed, although you can add more columns if you want. This of course does not help you, but what we can do is modify it through SharePoint Designer.
In SPD, connect to the site and open the "default.aspx" page. On the page (in code view), do a search for each of the following and delete them from the page:
<HTML>by </HTML><Field Name="Author"/> (this references the user who created the item) <Field Name="Modified"/> (this references the datetime is was last modified) Once these is removed, you'll no longer see the "By" or "Modified" information. This will not have any impact of the list itself, just on the "Summary" view being used on the page that holds the webpart. Alternatively, you can also just create a new view conatining just the columns you want to display and apply that view to the webpart.
If Apply to All the Sites (Note: Applicable for newly create announcement)
1. Added a "no author" view to the announcement list schema (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\AnnouncementsList\Announce\schema.xml).
2. Done by copying the summary view ... node,
3. Then making a change to the node similar to the allitems view (BaseViewID="1"), but giving it the name "No Author" and the URL "NoAuthor.aspx".
4. IISReset the server.
5. Create a new announcement list and bam! No Author view is available in the newly added web part.
The problems with this solution are:
It does not change all existing Announcement lists to add the No Author view. It adds a new view to the actual list rather than just giving me more options for setting the web part's view.
So... anyone got any ideas of how I can get the Summary View to be selectable on displaying the author info?
PS - this is a way you can take out the By: Author line on all Announcement list view web parts if that is what you want. Just remove the related sections from view zero, do an IISReset, and the author info will be removed from all announcement list web parts that are on summary view.
One issue that came up during a recent project was how to open items sitting in document libraries in Microsoft Office SharePoint Server (MOSS) 2007 in a new window. I had found various neat ways on how to do this in SharePoint Portal Server (SPS) 2003, including Todd Bleeker’s awesome Content Editor Web Part solution which entails adding a normal content editor web part with some slick JavaScript to a doc lib page that where upon the page loading most “A” tags on the page are modified to open in a new window.
This web part solution is great, and even works in MOSS 2007 interestingly, but my customer on this project was looking for an even easier solution that did not involve having to manually touch each document library at some point. After some further searching I found the steps to modify site definition files to change the inherit behavior of document libraries so that each time one is created it will automatically have this “new window opening” behavior. Andrew Connell had a great blog post on this.
All of this info was helpful, however the problem of course is that the site definition structure in MOSS 2007 is quite different from SPS 2003 and so the steps to make these granular modifications have changed. After some tinkering around I finally figured it out (or so it seems, the behavior seems expected so far, no weirdness has yet emerged!).
Steps to modify the site definition files in MOSS 2007 to open document library items in a new window:
1. Open the folder: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL\XML
Apparently there is now a “global” folder for site definition files, I am still trying to understand the mapping of things from SPS 2003 and MOSS 2007.
2. Find and open the file named “ONET.XML” in your favorite XML/text editor (good old notepad for me please)
3. On line 693 you will find this line of XML:
Changing this line to as shown below will change the behavior of the textual links to open in a new window
4. On line 838 you will find this similar line of XML:
Changing this line to as shown below will change the behavior of the image icon links to open in a new window
5. Save changes do an IISRESET and you should be good to go. Of course if you are in a medium or large farm scenario you will need to perform these steps for each front-end web server
The Search Results Core web part is quite easy to customise with XSL, which makes it a good out of the box solution for displaying data that comes from multiple sites or even multiple farms.
Unfortunately specifying the query to use is not quite so easy, limiting you to a hardcoded query with the fixed keyword query properties or whatever the user can type in to the standard search box. Sometimes this is enough, but the keyword syntax is too limited if you want to do something like return results newer than a certain date. For that you need to be using the SQL search syntax.
The advanced search web part uses SQL syntax and can get just about any result set you want. However, the UI is not really simple enough for the average user and isn't that convenient for searching lookup fields. Time to try customising the advanced search interface.
My first thought was to override the Advanced Search webpart. However, I on looking through the code in reflector I noticed that the advanced search webpart doesn't contain any code to build the query. That happens in a control called SearchResultHiddenObject, which is marked internal so there is no way to modify the construction of queries in code. On the other hand, the fact that the Advanced Search webpart doesn't do any special processing means that it can be safely removed.
Copying the html source for the webpart into a content editor webpart works quite well, or at least it did once I removed some of the table structure - "?Contents=1" is a very useful query string if your html breaks the menus. Note that you probably shouldn't edit the html directly in the cewp source editor, as it is difficult to get at the editor again if it is wrong, and you probably don't want to delete all your code, which is the only option the recovery interface gives you.
As well as the web part itself, you need to copy some script and hidden fields - the script block starts with the function DisplayNextProp and the hidden fields are ASB_TextDTProps, ASB_DateTimeDT_Props and ASB_ResType_Query.
Next step is to make a cut down version, getting rid of the table structure, giving me a relatively easy to modify form with all the original fields. The javascript can also be safely removed as it is only for updating the UI, and the whole point of the customisation is to replace that UI. I'm not sure what ResetPageHashCode does, but removing it doesn't seem to have any effect.
What we are left with is a set of html controls that can be modified as needed. There is no need to register the controls anywhere and the first part of the name is ignored - the SRHO just checks the part of the name starting with "ASB". All of the fields are optional, and the SRHO will ignore any missing values. The numbering of the controls with multiple instances such as the property controls has no special requirements - as long as they match the pattern ASB_PS_ they will work.
ASB_TextDT_Props and ASB_DateTimeDT_Props Are lists separated by "#;#" which specify the properties which will be treated as text and datetimes respectively when building the query. All others are treated as numbers.
ASB_ResType_Query is set by the result type dropdown and can be used to include some raw SQL. However, the SRHO requires at least one other piece of the query to be used.
ASB_PS_lolb_0 is the operator to use between properties - either "And" or "Or". This is required if multiple properties are checked and the same operator is used for all properties.
ASB_TQS_AndQ_tb is the "All of these words" search box.
ASB_TQS_PhraseQ_tb is for an exact phrase.
ASB_TQS_OrQ_tb is for "Any of these words".
ASB_TQS_NotQ_tb is for words to exclude. It can only be used if another search term is also specified.
The language checkboxes are named in the format ASB_SS_lcb_0_12 with a value of "on". The first number is a zero based index, while the last number corresponds to langdef values in the properties of a default search box. I'm not sure where those values come from.
Search Scope checkboxes are similar, with the format ASB_SS_scb_0_16 but no value set. The last number is the scope ID, which you can find in shared service administration.
Finally there are the property selectors. You can have as many of these as you want - just change the number at the end.
ASB_PS_plb_1 is the internal name of the property to search
ASB_PS_olb_1 is the operator, which will be one of the following values: WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorContain) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorNotContain) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorEqual) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorNotEqual) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorLater) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorGreater) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorEarlier) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorLess) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorTrue) WebPartPlatform.Current.GetLocResourceString(LocStringId.AdvancedSearch_OperatorFalse) or in English: Contains Does not contain Equals Does not equal Later than Greater than Earlier than Less than Is true Is false ASB_PS_pvtb_1 is the value to search for.
Putting this all together, we get the following code which when placed in a content editor webpart will provide a dropdown to choose from a list of known authors and display the results in a search core results web part on the same page (assuming the url in the submit button is set to the current page).
--- --- Author: --- --- --- --- ---
I have a pulldown menu (Status) and then two checkbox (Knowlegde) and I want the following function Status AND (Knowlegde checkbox 1 OR Knowlegde checkbox 2)..but how must I do that? I got the following code:
An issue that came up on a recent project was how can we search custom meta-data on document libraries in MOSS 2007? So for instance, let’s say that in a set of document libraries in a site or across a number of sites each will have a custom column named “Department” that is of a data type “Choice” and the possible values are each department in an organization. Now let’s say that end-users would like to use advanced search to use the Department field as search criteria.
I knew this was possible with SPS 2003, however, I sadly never had a chance or a reason to try it out – but now I did with SharePoint 2007, yippee! So in order to figure this out, I did a cursory search online and hit TechNet’s MOSS section, but alas, I could not find anything showing exactly what I was looking for. So through some brainstorming with a colleague and also some trial and error I was able to get it.
First off, let's create a custom column of type "Choice" in a sample document library. I've named mine "Department" and given it three possible value options ("Sales", "IT", "Marketing").
Now that we have our column created, we need to run a full crawl in the Shared Service Provider (SSP) to make SharePoint aware of this new piece of meta-data. After the crawl is run, our new property will be captured as (what in SharePoint parlance is called) a "Crawled Property", however that is not enough to perform searching on it, we need to also then create a separate "Managed Property" and map the crawled property to the manually created Managed Property (also as a side note, you can map more than one crawled property to a managed property). Once we do this, SharePoint will be fully aware of the property's existence and we can use it as search criteria. The steps for all of this are below: 1. Open up the admin page to the SSP that is hosting the web application your document library is sitting in 2. Click on “Search Setting”, then “Content sources and crawl schedules”
3. Find the content source that contains your site and perform a full crawl on it Now SharePoint is aware our your new piece of meta-data and we can create a "Managed Property" to map to it.
4. Go back to the "Search Settings" page for your SSP and click "Metadata property mappings"
5. On the "Metadata Property Mappings" page click the "New Managed Property" link
Now on this page, we need to fill out the form for our new managed property. We need to give it a unique name (be careful here because many are already used, such as "Department"), select the correct data type, and then choose which crawled properties map to this new managed property. In this case, it will be only one crawled property and it will be the custom column we had created earlier named "Department".
1. Give a name for the managed property (I chose "OrgDepartment" to make it unique). 2. Select the correct data type, in this case "Text" 3. Now in the "Mappings to crawled properties" section of the form, click "Add Mapping" to bring up the crawled property selection dialog
4. This is a cool little widget in that you can actually search for the property you are looking for, in this case "Department". So enter "Department" in the "Crawled property name" text box and click "Find"
5. In the results I found one named "Department(Text)" and chose that. Now this is something I am still not completely clear on because also in the results list was a crawled property named "ows_Department(Text)" and I am not sure which one is best to use, but I can say that choosing the one without the "ows_" prefix worked just fine. Maybe when better documentation comes out I can get to the bottom of this!
6. Once that we have this form filled out, click OK and perform another full crawl on the necessary content source
At this point our crawled property is now correctly managed, which is great, but in order to actually use it as search criteria we need to customize our search center advanced search page.
1. Once that we have this form filled out, click OK then go back to the "Manage Content Sources" page and perform another full crawl on the necessary content source 2. Go to a search center site and click "Advanced Search" 3. Click on "Site Actions" then "Edit Page" 4. In the "Advanced Search Box" click "Edit" on the top right then click "Modify Shared Web Part" 5. On the pane to the right expand the "Properties" section
In the "Properties" text box under the "Properties" section is the XML defining which properties are searchable when which "Result type" option is selected (such as "Word Documents" or "Excel Documents"). We need to update this XML snippet with the correct nodes to define our new "Department" meta-data. Copy and paste the XML into your favorite text editor and make the following updates:
1. In the node add the following line:
This now adds a definition for our managed property into the search page, however, we will still need to add one more node to make it searchable on the page. The "Name" attribute must match up to the name of the managed property we created earlier and whatever is in the "DisplayName" attribute will be shown in the drop-down list on the UI of the advanced search page.
2. In one of the nodes (it is your choice, each ResultType node points to a different document type or overarches across all or a set of document types.) add the following node:
At this point you just need to exit edit mode and refresh the page and -kapow!- your new piece of meta-data is available in advanced search as search criteria!
