Web Parts - Laura Rogers @WonderLaura

7/2/2010

The Text Filter Web Part – Without Having To Filter Exact Text

This applies to both SharePoint 2007 and 2010. In MOSS Enterprise, and the 2010 version of Enterprise. There is an out-of-box web part called the Text Filter Web Part. Basically, when you put this web part on a page, and put a list or library web part on the same page, you then create a web part connection that sends the text typed in the box as a filter to one of the columns in the web part, like this:

ch5[38]

The name Molly Clark had to be typed in exactly. So, if you typed “Molly”, this record would not come up.

People use the text filter web part when they just want to search a single column in a list or library. Otherwise, you’d simply use the “Search” box at the top of the screen, choose “This List” or “This Site” and perform SharePoint searches that way.

One more note before I get into today’s solution:

If you’re making use of site columns in your lists, there’s a setting where you can specifically select which columns you do NOT want to be searchable on the site. In Site Settings, click Searchable Columns. Put check boxes in the NoCrawl column for the ones that shouldn’t be searchable.
ch5[40]

Here’s how to set up the text filter so that any partial word searches will work

One problem: with this solution, I don’t think there’s a way to make the list automatically display all items by default before doing your filter.

So again, this involves a data view web part… and that “parameters” concept that I keep raving about.

Go to a web part page, open it up in SharePoint Designer, and insert a text filter web part and a data view web part of any list or library.
Click to select your list web part, click the Data View menu, and choose Parameters.
Create a new parameter. In the name column, it doesn’t matter what it’s called, let’s just call it FilterParam. In the Parameter Source drop-down box, choose Query String.
The Query String Variable needs to be the exact name of the column that you’d like to filter.
Click the Data View menu, and choose Filter.

The Field Name needs to be the name of the column you’re going to filter, and HERE’S THE TRICK: Form the Comparison, choose CONTAINS. For the Value, choose the name of the parameter that you created at step 3. Click OK.
Right click on the Text Filter Web Part, and choose Web Part Properties.
The Filter Name box is required. Make something up. If it’s going to be used to search the title field, you might want to call it something intuitive like “Search Title”. There’s also a box in the Advanced Filter Options, to control the width in pixels. Type in a width if you wouldn’t like the web part stretching across the entire page. Click OK.
Right click on the text filter web part, and choose Web Part Connections.
Choose Send Filter Values to. Click Next.
Connect to a web part on this page. Click Next.
Target web part: choose the name of your list. This part is important: The target action needs to be Get Parameters From. Click Next.
Click the name of the text filter on the left, and the name of your new parameter on the right. Click Next.
Click Finish and save the web part page.

Try it out. In the text filter, you can type any part of any word and hit enter. It doesn’t take Boolean expressions or anything fancy like that, but it’s much more useful than having to type the text exactly. Again, this is a solution that I just whipped up today, and can’t tell if there’s any way to make the web part show all items until you want to filter it. Nothing obvious. I guess if you need to have the whole list displayed, you can just insert a third web part on the page, as a full view of the list.

Technorati Tags: sharepoint,search,filter,web parts

Posted at 5:04 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (11)

6/29/2010

Display a Sub-Site List on a Top Level Site

In SharePoint 2007, it was possible to display any list or library from one site on another site in the same site collection, but to accomplish it usually entailed digging into SharePoint Designer and creating a data view web part. There was that little button when designing a data view web part, called “Connect to another Library”, which let you create a web part on one site, based off data in another site.

In SharePoint 2010, it is easy to put list or library data from a sub-site on a top level site in the same site collection, and it doesn’t entail creating any special web parts or breaking any pages off of the site definition! Here’s how:

Open the browser and go to the list or library that you want to ultimately display on another site.
Click the Library tab in the ribbon, and click the orange Edit Library button, to open it up in SharePoint Designer 2010.
In the Views section on the right, click on the name of ANY view, to open it up. Yes any. It doesn’t matter which view you pick here. Don’t worry, you won’t be modifying this page.
Put the cursor inside the content section of the list, so that the set of List View Tools tabs are displayed at the top.
Click the Web Part tab. In the Save Web Part section, there are two options:
- To Site Gallery – This option is used if you want to have the ability to insert this list onto any site page in the whole site collection.
- To File – This allows you to save the .WEBPART file on your computer, so that you can import that file onto any page in the site collection.
Click To File, and save it to your desktop. The following question pops up:

Do you want this Web Part to always show list data from the current web site? If you select No, the web part will show data from the list at the path ___, relative to the site in which it is used.

It is important to understand what this means. Click Yes to save this exact list. Click No, if you want this web part to be relative. So for example, if this is a list called Announcements, this web part would be used to display any list with the name Announcements that exists on the site that this web part is imported on. In this example, it’s a document library called Shared Documents.
Click Yes.
Close SharePoint Designer.
Go to the other site, on which you would like to display this list. Click to Add a web part, and click the little Upload button below all of the categories of web parts. Upload the web part and add it to the page.

This is where the AWESOMENESS became apparent to me. Now a default view of the sub-site’s list will be displayed AND you can go into the web part properties tool pane and change the view. YES, the familiar Selected View drop-down and Edit the Current view button are both available… even though the list you’re viewing exists on another site!

BUG alert 1: Unfortunately, the functionality described in this blog post only works when you’re viewing a sub-site’s information on a top level site. This doesn’t work the other way around (top level list on a sub-site) because when you try to import the web part on the page you get an error.

BUG alert 2: When importing any web part on a page, the upload functionality is a bit funky in 2010. Sometimes you have to upload the web part twice before it will stick, sometimes some other site list gets added to the page, and every time you have to click to insert a web part at least twice. The first time to upload it (then the list of web parts goes away), then the second time to add that web part to the page.

Technorati Tags: sharepoint 2010,web parts,sharepoint designer,data view web parts

Posted at 12:59 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (4)

6/26/2010

Phone Number Validation in SharePoint 2007

Yes, you can do ANY kind of validation such as phone numbers, email addresses, social security numbers, zip codes, whatever. If you’re really nerdy, you can even validate IP addresses. I just thought I’d catch your attention with the title, since phone numbers are one of the most frequent types of data that people need to validate. This is all done using regular expressions, with NO programming involved!

What is validation? It means that when you have a form with a box for someone to type their telephone number, you want to make sure they type an actual full phone number, in the right format.

Currently in SharePoint 2007, you can make a field required, and you can set it to a certain type of data such as a number or date. On the other hand, in SharePoint 2010, validation is now a built in option each time you create a new column in any list or library.

Guess what… this solution entails creating a data view web part!

In this example, I have 3 fields I want to validate:

Email Address
Business Phone
Social Security Number.

In a previous screencast, I showed you how to Customize Form Pages in SharePoint (Screencast), so this is the prerequisite for doing the validation. Once you’ve created a contact list, added a social security number text column, and opened the site in SharePoint designer and created the custom form, these are the steps you take to add the validation. This will need to be done on the NewForm AND the EditForm of your list.

In your custom form, click to select the Email Address field, and click the little chevron at the top right corner of it, like this:
In the Format As drop-down box, click to change the format to “Text Box”.
Click to select the text box, right-click it and click Properties, so that the Tag Properties toolpane will show on the left side of the screen.
Scroll to the very bottom of the tag properties pane to find the ID tag, and ~~rename it to EmailTextBox, like this~~: Correction! Don’t rename the text box. You’ll just have to remember which one is which.
Click the Insert menu at the top of the screen, select SharePoint Controls, and click on More SharePoint Controls. This will put a new toolpane on the right side of the screen, called Toolbox. Click to expand the ASP.NET Controls, and the Validation section in there:
In the form, put the cursor next to the email address text box, on the right of it. Double click the control called the RegularExpressionValidator to add it to the page. Then, double-click the RequiredFieldValidator to add it also.

I know what you’re thinking. If I’ve already set it up as a required field when I created the column in SharePoint, why would I need to make it required again? When you change a field to a text box in the form, it doesn’t recognize the SharePoint required field info at all.
Click to select the red RegularExpressionValidator, and then take a look at that Tag Properties tool pane on the left again. In the Behavior section, in ControlToValidate, select the ~~EmailTextBox~~ default name of that text box, which will be something like ff20.
Do the same thing with the RequiredFieldValidator. Set its ControlToValidate as the ~~EmailTextBox~~ default name of the text box.
You only need to add the RequiredFieldValidator if the field needs to be required. Otherwise you can leave it off.
Select the RegularExpressionValidator again, because now it’s time to set up the regular expression. In the Tag Properties pane’s Appearance section, set the Error Message to say:
Not a valid email address
In the Behavior section of the Tag Properties, go to the ValidationExpression box, and click the ellipsis button to see this, and select “Internet e-mail address” and click OK:

Here’s what the Tag Properties pane looks like when the Regular Expression Validator is selected:

THIS IS SO COOL. I know you want to, go ahead and try this one out, so ahead and save the page and hit F12 to preview in the browser. Try typing incorrect and correct email addresses, and you’ll see that when it’s not a real email address, the red error comes up.
Time do set up the validation for the other two fields. Repeat steps 1 through 10 for the social security number and phone number, but KEEP READING BECAUSE THERE’S A TRICK TO THESE OTHER TWO.
For the ControlToValidate box for each control, be sure to select the appropriate one (of the above three). The ErrorMessage obviously needs to be different for each field also.

SO HERE’S THE TRICKY PART THAT FRUSTRATED THE HELL OUT OF ME. In the regular expression editor, when you select the “U.S. Social Security number” or the “U.S. Phone Number” patterns, they (and others) JUST DON’T WORK, so here’s how to fix them…

First of all, this is the pattern for a social security number:

It’s 3 digits, then a hyphen, then two, a hyphen, then four, like 765-76-9900. See in the pattern in the box above, the numbers with the curly brackets {} around them represent the number of numbers in a row. The problem is that SHAREPOINT DOESN’T LIKE THE CURLY BRACKETS. So, any time you see a pattern that has curly brackets in it, you have to modify it. So the above pattern for a SSN would need to be modified to be:
\d\d\d-\d\d-\d\d\d\d

Same goes for the phone number. Here’s what the modified phone number expression looks like:

This is the finished version of the NewForm. Again, you’ll need to do the exact same thing on the EditForm. I’ve typed a couple of them incorrectly, so each shows me an error message and the form can’t be submitted until they’re correct.

Here's my associated screencast, showing this process: Validate Email Addresses and Phone Numbers in SharePoint 2007 (Screencast)

In all my frustration figuring this out, here are the good reference sites that I came across, regarding regular expression patterns, in case you want to create your own:

Regular-Expressions.info

How To: Use Regular Expressions to Constrain Input in ASP.NET

Regular Expression Library

Technorati Tags: SharePoint,validation,MOSS,data view web parts,regular expressions

Posted at 3:50 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (15)

6/25/2010

SharePoint 2010 Related Lists (Part 4 of 4)

Yes, the title of this post is a little confusing, especially if you read the other 3 part, but let me explain. The first three parts of this series were all about the Query String URL Filter, and how to create mashups that display multiple related lists on one page. Lists have a lot more relational capabilities now, which is seen everywhere from lookup columns to workflows. So, since we’re talking about mashups and related lists, I thought I’d show you the Related Lists button in SharePoint 2010, which lets you quickly throw a few web parts on a page, and automatically connects them. So, another title for this blog could be “how to do the stuff from the other 3 posts… in SharePoint 2010”

In this example in SharePoint 2010, there is a main projects list with several lists with related items that lookup to the projects list. Let’s create some simple ones quickly, just to try it out.

Custom list on the site called Projects. To try it out, all you need is a Title field.
Create a new Issues list on the site. Create a new required lookup column in the list, called ProjectID, and make it look up to the Project’s Title field.
Create a new Project Tasks list, and also add a required ProjectID field that looks up to the Project list’s Title field.
Create a few items in each list, with some tasks and some issues associated with each project name.
Go back to the Projects list. Click to create a new view, name it Mashup.
On the new view, click Site Actions and choose Edit Page.
CHECK IT OUT!!! There’s a button in here to Insert Related List!!!
Click the Insert Related List button, and the drop-down will show the Project Tasks list and the Issues list. Insert each one on the page.
On the Page tab in the ribbon, click Stop Editing. This is what the page looks like now:

DONE. WOW, it’s going to be so easy now for end users to be able to create their own related list views, without even having to know how to create the web part connections!

How did it work? Since the Issues and Project Task lists contained Lookup columns to the Project list, SharePoint automatically knew to consider them “related lists”. If a list has no other lists that look up TO IT, then the related lists button will be grayed out.

One more thing… yes, the Related Lists button does exist in SharePoint Designer 2010 also, and not just in the browser.

Technorati Tags: SharePoint 2010,web parts,web part connections,related lists,projects,SharePoint Designer

Posted at 5:36 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (5)

6/12/2010

The Query String URL & Data View Web Parts (Part 3 of 4)

In the last two posts of this series, I showed you how to use the MOSS Enterprise out of box web part called the Query String (URL) Filter. This post will show you how to accomplish the same thing, but without MOSS. This entails using the data view web part. I’ll use the same example of a project details page. The query string will be used to pass the project ID to each of the data view web parts on a page.

Even if you DO have MOSS, another good reason to use data view web parts for mash-ups, is that redundant column that you’re connecting to. You know how when you’re creating web part connections, the only columns available for the connection are the ones that are being displayed in the web part? When data view web parts are used, ALL list fields are available in the connection, not just the displayed ones!

Here’s how to configure each web part in SharePoint Designer, to use a Query String:

Create a blank web part page, and open it in SharePoint Designer. Insert a data view web part, we’ll just start with the issues list. Again, this is using the same project details example, so please read my last post about it.
In the Data View menu in the toolbar, click Parameters.
There will already be one parameter. Add a new Query String parameter, called “ProjParam”, like this:
In the Data View menu in the toolbar, click Filter.
Create a filter where the ProjID field is equal to the new parameter [ProjParam]:
Save the page. Make sure there are a couple of items in the list, each with a ProjID associated with them. Open the web part page in the browser and test the query string.

The trick is that now you use the URL in order to pass the project number to this web part. This is supposed to be a project mash-up, so add all of the associated lists to the page as data view web parts, and repeat steps two through five on each one.

The URL to the page will now end with the page name.aspx?Project=2

That red number is unique to each project. In my previous post, I showed how to create the workflow that generates that project details URL for each new project. This screenshot shows that this list is automatically filtered by issues that have a ProjID field equal to one, because of the URL.

ch7[11]

In summary, here’s a brief comparison:

Query String (URL) Filter Web Part

Out of box web part
No SharePoint Designer needed
MOSS Enterprise version needed

Data View Web Part With Query String

SharePoint Designer data view web part creation needed
More complex setup
Can be done in just WSS, without MOSS

Note that you can still create all data view web parts, and still use the Query String URL Filter Web Part. This combination method will let you get rid of all of the redundant columns, in this case the ProjID… with the ease of use of the out of box query string URL filter web part.

Technorati Tags: SharePoint Designer,MOSS,Web Parts,data view web parts,Query string url

Posted at 7:34 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (1)

5/27/2010

Web Part Connections – Improved in SharePoint 2010

In SharePoint 2010, when you put a list view web part on a page, go to the web part tool pane, and switch the Selected View in the drop-down box, the following message pops up:

The part about disabling web part connections isn’t true anymore. Back in SharePoint 2007, when you created web part connections you had to make sure that the columns being filtered were actually displayed as columns. The connection configuration only let you choose from those visible columns. You can get around this by creating these lists as data view web parts in SharePoint 2007, which allows all columns to be available for filtering.

Anyway, in SharePoint 2010 this message isn’t valid anymore because ALL COLUMNS in the list are ALWAYS available when creating web part connections. So… don’t worry about it, and click OK. That’s all.

Technorati Tags: sharepoint 2010,sp2010,web parts,data view,web part connections

Posted at 11:42 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (0)

5/22/2010

Query String URLs are Magical (Part 2 of 4)

In my last post, I showed you what query string URLs are, and a simple example of what can be done with the MOSS Enterprise Query String URL Filter Web Part. In this post, I’ll get more into a really cool example of what can be accomplished with query strings, and taking it to the next level.

In this example, we have a site with

Project List
Tasks
Issues
Change History
Status Reports

The point is that all of these lists have something in common… the project. The main project list can have multiple items associated with it, from each of the other lists. We want to display all of these items on the same page in SharePoint. So, we create a “Project ID” field, which will be used as the common thread. We’ll start with the built in ID field in the main project list, and in each of the other lists, create a number field called “ProjID”.

I usually use workflows heavily in a solution like this, but this post isn’t really about that part. For now, I just want to show you how to create the “Project Details” page that shows all of the associated info for any given project, in which all associated lists have one common field.

Create a blank web part page, which will be used as the project details page. Use the method that I showed here, create a blank ASPX page called ProjectDetails.aspx, and save it somewhere like the root of the site.
A workflow step needs to be created on the main project list, so that each time a new project is created, a special URL is created for that project, for the details page. So first, in the main project list, create a new hyperlink field, and call it Detail Link.
Open the site in SharePoint Designer. Create a new workflow, and associate it with the main Project list, so that it runs when a new item is created.
The workflow has no conditions. For the first action, choose Build Dynamic String. Click the blue words “dynamic string”. Type in the URL to the new ProjectDetails.aspx page that you created at step one (this can be a relative URL, if you’d like). At the end of the aspx, type ?Project=

Then click the Add Lookup button, and choose the ID field from the current list. At the end, it’s important to put the comma space “Project Details”, exactly like in the screenshot above.

So, WHY are we doing all this? What does it mean? Well, this is the bread and butter of how your query string URL works. In my previous post, I explained query strings. We’re going to create a “query” called Project, and we’re going to use the ID as the unique identifier for the project. This is going to be the same number that is tied back to all those other lists related to this project, that will exist as the ProjID. The word “Project” above in the URL.. we’re just making it up for now (it doesn’t come from anywhere else at this point, and isn’t yet related to any fields or anything we’ve done so far). The reason for the comma space and Project Details, is that this is how you form the hyperlink, so that Project Details will be the actual words that users click on to get to that detail page.
Name this variable ProjDetailURL (instead of the default word “variable”)
The next action of the workflow is Set Field in Current Item. Click the blue word “field”, and select the Detail Link field that you created at step two.
In the blue “value” box, click the little function button, and select Workflow Data as the source, and pick the ProjDetailURL variable that you created at step five.
Click Finish to complete the workflow.
In the browser, go to the ProjectDetails.aspx page, so you can start populating it with web parts. In Edit Mode, click to add a web part, and add all of the associated lists, which in this example would be all of those bullet points at the beginning.
Also add the Query String URL Filter web part to the top of the page.
Edit the views of each of the list web parts on the page, and add the ProjID field to the current view for each.
Go to the web part properties of the Query String URL filter web part. For the Query String Parameter Name, type “Project”, like this screenshot below. This word “Project” ties back to step four. Use the same word here that you used there. Click OK in the web part tool pane.
Time to create all of the web part connections from the Query String URL, to each of the other web parts on the page. We’ll start with the Project List.
With the page in edit mode, click the Edit button at the top right corner of the Query String (URL) Filter Web Part.
Click Connections –> Send Filter Values To –> Project List. Choose the ID field, and click Finish.
On the Query String filter web part again, click Connections –> Send Filter Values To –> Tasks. Choose ProjID as the consumer field name, and click Finish. (This is why we did step eleven. If the field is not showing in the view, you can’t create a connection to it.
Repeat step fifteen, creating connections from the Query String URL filter web part to every single other web part on the page. After all the connections have been created, the web part will look like this:
Then Exit Edit Mode. All done!

Time to try it out. Put a query string in the URL, and you’ll see that it will automatically filter all the web parts by that one project ID. Notice the browser URL, the fact that the Query String URL filter web part is hidden, and that all of the web parts show the filter symbol in the appropriate column. Click the picture below to zoom in.

To finish it out, try creating a new Project in the main project list, the one we associated the workflow with in step three. Check out the resulting URL that the workflow creates, and you’ll see that it takes you to the project details page for that project.

Yes, I agree that displaying the ProjID on all of those web parts is quite redundant. You can make any or all of those web parts as Data View Web Parts, and you don’t have to display the ProjID as a column. It will then let you create connections to the web parts using any fields in the list, not just displayed ones.

Obviously this is not a complete solution, but a piece of a puzzle. The rest of the solution would entail workflows that automatically create tasks at certain phases of the project, and form pages that let you click to create a new issue or status report for that project. Maybe this series of blog posts will be more than four parts. ;-)

Here's my associated screencast:
MOSS Enterprise – Query String URL Filter Web Parts – Ramping It Up (Screencast)

Technorati Tags: query string url,sharepoint,web parts

Posted at 2:39 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (2)

5/20/2010

Query String URLs are like, SO Useful! (Part 1 of 4)

In this blog post, I’ll not only explain what Query String URL Filter web parts are, but what the whole concept is behind query strings, and some ways to make use of them in SharePoint. First of all, what is a query string? Basically, it’s a part of a URL that contains a filter, to send filter information to the page that you’re viewing. These are used all over the place on the web, not just in SharePoint. The basic syntax consists of a question mark followed by a word, and the “equals” something. So, if you are looking at a web page that consists of information pertaining to the marketing department, your URL could end with this query string:

?Department=Marketing

In SharePoint, if you have MOSS Enterprise, there’s an out-of-box web part called the Query String URL Filter. But, as I will show you later, you can still do query string filtering if you don’t have MOSS Enterprise.

So begins the love story between me and query strings…

The first time I used them was when I created a policy management system in SharePoint. Picture this, a library of policies, with a Department column in the library, and each policy was associated with a department name. To create a list of policies for each department, you could create multiple views on the library, with each view just being filtered by the Department column being equal to ___ (each department name). Well, I didn’t want to do this, because I didn’t want to have to go back and modify 30 different views if the business owner decided that a column needed to be added or something. So, instead, I did this: CropperCapture[110]

Go to the default view URL:
http://contoso/policies/PolicyList/Forms/AllItems.aspx
Click Site Actions and Edit Page.
Insert the Query String URL Filter web part on this AllItems.aspx page, above the document library.
Go into the filter web part’s properties, shown in this screenshot.
In the Query String Parameter Name, put a word that describes the field you’ll be filtering by. The Filter Name can optionally be changed, but it doesn’t really matter.
Click OK in the web part tool pane.
Connect the Query String URL Filter web part to the list or library web part that you’d like to filter. In this case, it’s a list of company policies, in which I’m going to create a filter for policies related to each department name. At the top right corner of the filter web part, click the Edit button and choose Connections –> Send Filter Values To –> and choose the name of the library, in this case it is the Policy List, as shown in this screenshot:
On the Configure Connection screen, pick the Consumer field. The consumer web part is the one you’re sending the filter to. The Policy List here. I’m filtering by the Policy Department, so that’s what I pick in the drop-down box.

Note that whatever field you filter by needs to be displayed as a column in the web part in order for it to be listed in the drop-down box on this screen. If you’d like to filter by a column and NOT display it in the web part, that consumer web part needs to be a data view web part.
Click Finish and Exit Edit Mode.
Manually create a link to each department’s list of policies. Put these in a links list or in the Quick Launch or wherever. Here’s an example of what the filtered list of IT policies looks like:

Notice a couple of things. See that the Policy Department field shows that little filter icon, and it shows only the IT policies. Also notice the URL. It is:

http://moss:16071/policies/PolicyList/Forms/AllItems.aspx?department=it

Note: If you insert this web part on your default view, just remember that when new views are created, they will be based on this default view (by default) and they will also include this extra web part, which you may need to remove from new views.

I’ve demonstrated a very basic way that the Query String URL filter can be used. Once you understand the basic functionality, there are many more things you can do with it. Part 2 of this 4 part series will cover a more advanced, elaborate solution.

Technorati Tags: SharePoint,web parts

Posted at 6:54 AM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (0)

5/19/2010

Setting Permissions on SharePoint Views

Here’s a little hack that you can do, in order to create permissions on views of any list or library. I’m not going to say this is the most pretty or perfect solution, but it’s at least a way to accomplish this. It gets asked all the time. “How can I set permissions so that only certain people can see certain views of my list?”

Maybe you have a situation that the default view of a list shows users only items that they’ve created, or only items in a certain filter like by department. That’s the only view that you want most users to see, except maybe “Managers” get an additional view with information pertaining to them. Anyway, here’s how you can do it. First, the high level:

Create a library to put web part pages in.
Create a new web part page in that library
Insert a data view web part of your list on the web part page
In the data view properties, turn on the SharePoint list toolbar and SAVE

Now, when you go to the regular default view of your list or library, you will see a new view in there with the same name as your list. Clicking on this view name will take you over to the web part page you created. This hack will allow you to change the permissions on your web part page. The resulting behavior is that users who click on that view name and don’t have access to that aspx web part page will get an access denied message. I know, it’s really disappointing that the “view” drop-down box isn’t security trimmed. Now, if you’re still interested, here are all of the steps to follow:

Create a document library on the site called “Views”.
Create a blank web part page, preferably using the method in my previous blog post Create a Web Part Page WITH a Quick Launch Menu and save that web part page in the doc library from step 1.
In SharePoint Designer, open this new blank web part page. Click the Data View menu and click Insert Data View.
Click the list or library, click Show Data, and select the fields you need and drag them into the web part zone. (If you need more help with inserting web part basics, check out my data view web part series of screencasts)
Open the Data View Properties screen. On the General tab, put a check next to the SharePoint List Toolbar. Click OK.
Click File and Save As, and save it to the document library created at step 1. Close SharePoint Designer.
This is probably something a lot of you have noticed before. Now, your list will have a new view in the list of views, that has the same name as the list itself. You can go to the document library settings, scroll all the way down to the Views section, and click on that view and rename it.

Here’s what you can do with this weird little hack. Notice that now when you click on that view name in the regular list, it takes to over to that web part page and the data view web part you created… over in that other document library called “Views”. This gives you the ability to set permissions per view! In the Views document library, click the drop-down box on that ASPX page that you created, and click Manage Permissions. Assign permissions to only the people who should have access to this view. Note that this is not a substitute for item level permissions. Users could technically still go to any of those list items, so this solution is not feasible in a high-security situation.

The end result is that each view that you create as a web part page is listed in the View drop-down box of the list or library, and people who don’t have access to that view ASPX page will get an Access Denied page if they try and click on it.

Again, this is not a perfect solution, but it gives at least some way to accomplish “view permissions”. Try it out and see what you think.

Technorati Tags: SharePoint,views,view permissions,web parts,data view web parts,web part page

Posted at 9:48 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (7)

Create a Web Part Page WITH a Quick Launch Menu

This is just a very quick how-to post. I can’t stand those default web part pages for anything besides testing, because you lose the Quick Launch navigation, so I usually create a blank ASPX page instead. These are the steps to take to create your own web part page. This is also a useful method for creating custom form pages for your lists.

Create a document library to put your web part pages in.
Open your site in SharePoint Designer, and click File –> New –> ASPX
Click the Format menu, choose Master Page, and click Attach Master Page
Click OK for the Default Master Page.
Click the PlaceHolderMain section in the middle of the page, click the little chevron (the little gray button with an arrow on it), and click Create Custom Content.
Put your cursor inside of the PlaceHolderMain section. On the Insert Menu, choose SharePoint Controls, and click Web Part Zone.
Click File and Save As, and save it to the document library that you created at step one.

Now you have a blank web part page that DOES contain the Quick Launch navigation on the left. You can either add web parts here in SharePoint Designer, or from the browser. F12 will take you directly to that page in the browser.

Another hint: If you’d like to have multiple web part zones, step 6 would be to create a table first, and then insert the web part zones into each cell of the table.

Here is my screencast on this whole process: Web Part Pages - Making Your Own

Technorati Tags: SharePoint,web parts,web part zones,aspx,web part page

Posted at 5:03 PM by Laura Rogers | Category: Web Parts | Permalink | Email this Post | Comments (4)

1 - 10