I'm attempting (futilely) to create a custom advanced search page for my department's SharePoint site. I've been using this article as a guide,
http://tqclarkson.com/2007/10/26/creating-a-custom-advanced-search-box-in-moss-2007/
I've had some success copying the code of the advanced search web part and modifying it to my needs. However, I'm having some struggles with scopes.
Some background...
We are currently running MOSS 2007
Our company houses all its intranet sites under one GIGANTIC site collection
I am a site owner, but not the site collection administrator (that is controlled by IT corporate). Therefore I don't have access to central administration which houses most of the search settings.
IT has not set up any custom scopes (and just trust me when I say asking them to do so would be completely impractical).
I need to scope the advanced search web part's queries to just our site or its libraries. In a perfect world, I would just create custom scopes for this purpose, but as I mentioned that's not an option here.
I've tried using the URL property to restrict the results. Problem is the search has to be executed on EVERY RECORD in the database (which I'm sure is unfathomably huge). I did a test query which took over 5 minutes to result! Definitely not a practical solution.
So that's where I'm stuck. I need to scope the queries but can't figure out how else to do it. Any advice is welcome. Thanks as always!
Related
We have a special situation at our office where we "close" off a site collection when a project is complete. Our architecture is setup such that each project in play is it's own site collection. When the project is complete we close the project in SP by setting the site collection to read-only.
Part of our business would like to still view the closed site collections, but doesn't want to go through a list of them (I mean excel spreadsheet or some other external form of tracking), but instead wants to do it from a page in SP. Our solution is to modify one of our other solutions (search query web part that finds all site collections they belong to) and only search on closed site collections.
I know how to determine if a site is ReadOnly or not in Powershell (#spSite.IsReadOnly), but that isn't going to work here and going through the properties in search I couldn't find anything that jumped out at me to do this. Does anyone know how to return ReadOnly site collections in a Search Query Web Part?
Thank you.
I know of a managed property called: SiteClosed but I haven't got the slightest idea what it does. Looking at the name this might be the one to start with.
If this doesn't work I'm afraid the only other option is to create a custom Web Part...
We have recently moved our project over to TFS 2010 for CM control and issue tracking. For the most part we have been happy with the move. However, we have found that we need a way to allow users (notably our help desk) to write dynamic queries against our Product Backlog. The Query Results Web Part works fine for displaying information like Outstanding Work Items and Recent Issues, but our users need the ability to query for specific information that can change from support call to support call. Is there a way to allow a user to create a custom, dynamic query in TFS? If not are there any 3rd party tools that integrate with SharePoint that would allow this?
Thanks.
TFS 2010 has a web based user interface called Web Access. Users can create and view their own queries from there with the queries part of te app; they can also search for work items by words contained in their titles
By default, there is typically a link on the upper-left to it from the SharePoint site that TFS 2010 creates. If the link is not there you can access it directly its (default) URL: [http://address-of-your-TFS-server:8080/tfs/web]
I decided to use the Page Viewer Web Part to embed the actual query form from the Team Web Access to the Project Portal. Everything seems to work great when doing that. The only downside is you get a 'Nag Dialog' whenever you leave the page.
We'd like to create a web page that will list all Document libraries across all sharePoint Sites for the user currently accessing the page. We'd also like to offer a all site search for the user. That is all sites they have access to.
We currently do not have Mysites enabled, nor do we want to.
Possilbe to code this?
All site search is easy. If you are using the non-free version of SharePoint 2007 or 2010, then that capability is baked into the product. Users can use the search scopes to search across all content in the SharePoint farm. It will automatically trim search results that users don't have access to.
As for you list of all document libraries, this would probably be too much effort to generate in real time for any non-trivial SharePoint environment. You are most likely going to have to gather this information ahead of time and then display the appropriate summary of the data in a WebPart of some other similar interface. Code to crawl every web application and every site and every sub-site and then every Document Library isn't hard. Actually it is very straightforward. What will be a little tricky is that you will need to collect ACL entries for each of these lists so that you can compare them to the current end user. The real trick is that the ACLs might contain SharePoint Group names and Active Directory group names instead of individual end user names. That will make your reporting task more difficult.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I'm currently planning the migration of a Microsoft Content Management Server (MCMS) website to a SharePoint 2007 publishing site.
The top-level site is a public facing, anonymously-accessible website. It will contain two areas which need to be protected with forms-based authentication - each of which will have a distinct set of users.
There is content in the current MCMS site which uses "Connected Postings", which is the ability to use content in multiple places without duplicating it. In SharePoint, a similar concept is supported via the Reusable Content list, but this doesn't span site collections.
I'm thinking that this should be a single web application with three site collections. 1 for the public facing site, and the others for the two protected areas. However, I'm not sure if 1 site collection can be anonymous, with the other 2 implementing different FBA authentication providers.
I'd like my Urls to be something like:
www.whatever.com
www.whatever.com/protectedarea1
www.whatever.com/protectedarea2
Without Url rewriting, this would be difficult to do with separate web applications.
If I end up having to go with 3 separate web applications in order to get authentication to work as desired, I will probably have to get creative with content deployment so as not to duplicate content during authoring.
Would appreciate any thoughts, thank you!
Don't do MCMS so cannot answer specific to that, see http://www.andrewconnell.com/blog/ for alot of info.
Microsoft has a bunch of different designs for extranets, http://technet.microsoft.com/en-us/library/cc263513.aspx depending on your needs. You can set it up as you are describing, forms are a little weak put their is some a better version available on CodePlex.
For the URLS, Sharepoint has a feature called "Manged Paths" that will do what you want. No URL rewriting needed.
Our setup is a site collection for extranet and internal, where most work is done. When finished they can publish it(does make an extra copy) to the public site. Some public sites are publish only sites where they have no interaction with non-account people, some are sites were they actually do most of their work and non-account people can make contributions. All are available under MOSS.
Thanks, that extranet link will be helpful when looking at separating the authoring environment from the publishing environment.
I was trying to implement two FBA membership providers on two site collections within the same web application. Doesn't look like I can do that, gonna try using the same membership provider with different roles.