SharePoint Blank

Applying a Filter to a SharePoint List

2008-12-03T22:40:00Z

I've mentioned filters in passing a few times in the past, but it occurred to me earlier today that I've never really lingered over the topic. As regular readers have probably sussed out by now, such realizations tend to lead to dedicated blog posts, and today won't be any exception. I'm limiting this initial look at filtering to the basics of working with filters in a single list view, but this is a topic that I will likely return to in the future with some fancier data manipulation methods (read: after I've learned them).

I'm going to look at the filter options associated with the Default list view, which presents the following appearance by default:

As you can see, the options are to Show all items in this view (which is to say, don't apply a filter at all), or Show items only when the following is true (i.e., apply a filter based on the following conditions), which will only display the relevant results in your list view.

If you choose to apply a filter, the dropdown menu associated with the field immediately beneath Show the items when column will display every column in your list. These options will naturally vary from list to list, but so as to provide a visual representation, here's what one such dropdown menu looks like on our site:

The second dropdown in the Default view's filter process is the is equal to menu. This is where the magic starts to happen:

As you can see, what this field does is give you a range of options to divvy up your data by taking your chosen column data from the first dropdown menu, and apply the is equal to rule to that data. (Note: The default list of filtering options is fairly robust, but custom filters are also available in SharePoint, so don't think that this is all there is to the subject.) Based on the is equal to option you choose, and based on the nature of your data, you'll enter content in the input field beneath the is equal to dropdown and this will result in the first point of comparison in your filter.

As you can see, there is a second (and identical) set of these same three fields which appears under the When column heading. This end result of this second set is what you're comparing the first set's result against, and it's this action which completes the filtering circuit. The key option to take note of here is that you can take the result from the first set of fields and apply them against this second set by choosing to use either an and or an or operand.

Once you've completed the above filter setup, if you find that you need to apply multiple filters, simply click the Show More Columns... hyperlink. Doing so will render another set of the aforementioned When column fields, allowing you to daisy chain your filtering options.

Once all of your filtering options have been finalized, click the OK button (not pictured) at the bottom of your screen, sit back, relax, and watch your filter work its magic on your SharePoint list.

Pimp my My Site: Adding a My Links Web Part

2008-12-02T22:43:00Z

While casting about for today's blog topic, I realized that it had been a while since I'd dressed up my My Site with some new bling. This being the case, I decided to treat myself to a new Web Part, and while scrolling through the available options, my eye was drawn to the promise of a simple yet useful add-on for one's My Site: the My Links Web Part.

The My Links Web Part is exactly what it sounds like, a Web Part which you can customize to display any set (or sets) of links you desire. Think of it is as an at-a-glance "favorite places" module. Naturally, you're not limited to SharePoint sites on your intranet, and you can include any Internet URL that you wish.

To add the My Links Web Part to your My Site, begin by choosing the Edit Page menu option from the Site Actions dropdown button:

On the resulting Edit Mode rendering of your page, choose your preferred Zone for placement of the Web Part (I chose the Middle Right Zone), and click the Add a Web Part button for that Zone:

On the resulting popup, locate My Links in the list of available Web Parts, select the checkbox, then click the Add button at the bottom of the list:

Your page will automatically refresh (still in Edit Mode) with the default instance of the My Links Web Part placed accordingly:

Remaining in Edit Mode, it's now time to populate your links. To do so, simply click the Add Link hyperlink (as pictured above), which will render the Add Link page:

As you can see, the basic Link Information requirements are to provide a title and URL for each link. Additional options include Privacy and Grouping, which enable you to limit who can see your links, and to place those links into groupings. Any New group that you add in the input field will appear in the Existing group dropdown thereafter. Once you've typed (or pasted) the information for your first link, click the OK button. Note: Doing so will refresh the page, exiting Edit Mode in the process.

I added a new grouping called Blogs, and added a link to SharePoint Blank, so when my page refreshed, the Web Part looked like this:

To add additional links and/or groupings to the Web Part, simply rinse and repeat the above process by clicking the Add Link hyperlink again. To modify existing links, use the Manage Links hyperlink.

And that's pretty much the scoop on the My Links Web Part. It may not be the flashiest Web Part on the block, but it'll work for your love.

Folder Name Headings in your SharePoint Shared Documents?

2008-12-01T20:55:00Z

A question came in via email recently which immediately generated a chuckle, since the message began, "As you seem to be quite expert on the whole SharePoint thing..." Though I certainly appreciate a compliment as much as the next blogger, modesty demands that I point out that the key word in that sentence fragment is seem. I think I've learned a fairly respectable amount as a SharePoint end user over the past 6+ months, and that's due to a combination of factors (including the genuine SharePoint experts with whom I'm fortunate to work, the excellent instructors at Mindsharp and Learning Tree and, yes, my own inquisitive nature), but expert? Nah, I'm just a fellow traveler, doing my bit for the community.

Without further ado, the question on today's docket is:

Can you tell me how I change the headings at the top of each document folder to match the folder name, and not say 'Shared Documents' wherever I am within the structure.

I want to keep all my folders under 'Shared Documents' but I want people to see a heading at the top of the page clearly saying which folder they are in!

Through a reasonably exhaustive combination of efforts undertaken within our site, I arrived at the conclusion that this couldn't be done out of the box ... at least not in my MOSS environment, and so I imagine the same holds true for WSS. The folder name will consistently appear in the breadcrumb, but can't be made to overtake the document library heading (e.g., Shared Documents) itself as the main heading.

I held out some hope that this could be accomplished via a third-party offering, so I did some Googling. When Googling didn't provide satisfaction either, I brought out the big guns and consulted Jeff Kozloff, one of the aforementioned colleagues who is a genuine SharePoint expert. Alas, Jeff confirmed for me that it can't be done out of the box and, while he thought it might be possible to achieve the desired result via the passing of a token within SharePoint Designer, that potential workaround didn't bear fruit either.

I'm sad. This is the first time one of these investigations has ended in disappointment, with seemingly no hope for SharePoint satisfaction. Since I'd hate to have to end on a downer, however, I'll say that I can't imagine that it's impossible to achieve this functionality. If this is must-have functionality for your organization, I would invite you to engage our Custom Solutions team, and I bet they'll be able to provide a more agreeable answer to the question.

Managing SharePoint Alerts with the Bamboo Alerts Administrator

2008-11-26T21:32:00Z

Having now mentioned the Bamboo Alerts Administrator twice (in two days, no less) while answering SharePoint alerts-related questions that had been submitted by readers, I figured I should probably spend some quality time with the Web Part. As a result, this will be the first entry in what may very well become a semi-regular feature of SharePoint Blank, providing me the opportunity to approach Bamboo products from the same angle that I approach SharePoint in general ... as an inquisitive end user who's looking to gauge both the ease of use and relative usefulness of included features.

Once it's been installed on your site, the Alerts Administrator is available to all users with admin permissions, and is conveniently available from any page in a site which features the Site Actions dropdown menu:

Selecting its menu item from the dropdown menu will render the Alerts Administrator page, which includes a complete list of the alerts that currently exist for all site users. Here's what the default view of the Alerts Administrator currently looks like for the Online Operations team (affectionately referred to as the "OOps team") here at Bamboo:

Taking the features from the top, you'll notice the quick hits toolbar, with its Add, Delete, and Toggle options:

The Delete button will, naturally, delete selected alerts from the site (after a confirmation popup). Come to think of it, since I need to clean up the extraneous alert I signed my colleague Chris Dooley up for in the course of writing yesterday's blog entry, I'm going to use the delete feature to zap that sucker from the site right now.

Toggle allows you to disable selected alerts without deleting them (conversely, as its name implies, Toggle also allows you to enable selected alerts which had previously been disabled). As you would expect, disabling an alert switches its status to Off in the Status field of the Alerts Administrator.

The Add button will refresh the page with a view of every object on the site that qualifies for an alert, divided by default into categories, as you can see below with the categories represented by Discussion Boards, Document Libraries, and Lists:

Clicking the Category bar allows you to reverse the alphabetical order of the categories and the objects within them, and the grouped categories can be ungrouped simply by dragging the Category header out of the blue bar. Placing a check next to one of the items in its checkbox and clicking the Next button will render the familiar SharePoint New Alert page, with all of its attendant functionality.

As you can see, the bar immediately beneath the toolbar in the default view instructs that you may Drag a column header and drop it here to group by that column:

I'm going to do just that, and group my alerts by User for a more manageable UI:

Having done so, you can see that User now appears in the bar beneath the toolbar. This User field behaves just as the Category bar did in the Add UI as described above. As such, clicking the User field will rearrange the alphabetization of the groups and their contents (reversing ascending to descending or vice versa), and dragging the User field out of the bar will ungroup the list contents.

Continuing our top-down look at the Alerts Administrator, our next stop is the columns header bar:

The checkbox in the upper left is a select all option, and the contents of the columns themselves (User, Site, Title, Alert Type, Event Type, Alert Frequency, and Status) can each be filtered thusly:

Moving on to the main event, the alerts list, you'll note that each column is auto-populated according to its contents for each instance of an alert:

As you can see, each column is collapsible via the button at the extreme left (next to User in my example). Under the User bar, you can see the checkbox which will enable you to select a specific alert. To the right of the checkbox is an additional Toggle switch, which allows you to toggle a specific alert without having first selected its checkbox. Needless to say, green equals on, and toggling an alert to off will switch the associated toggle icon to red. The X you see to the immediate right of the Toggle switch is another means of deleting an alert. In this case, the associated checkbox must be selected before the X/Delete button becomes enabled.

The Edit icon, which is just to the right of the X, is the final icon of our tour, and this may very well be my favorite feature of the Alerts Administrator since it provides extremely useful functionality which, as I discovered yesterday, simply doesn't exist out of the box in SharePoint. Which is to say, it provides the ability to not only modify an existing alert, but it allows you to do so easily by auto-creating a dropdown menu for any alert instance, like so:

Since it's entirely possible that I missed some functionality in my tour of the Alerts Administrator, I invite you to check out the dedicated Bamboo Alerts Administrator page in our storefront for additional information.

Modifying SharePoint User Alerts

2008-11-25T21:25:00Z

In the process of responding to Nate's question about how to view SharePoint user alerts yesterday, I was appalled to discover another alerts-related question that had been posted over a month ago which had somehow gone unnoticed and, consequently, unanswered. I immediately offered my apologies, then went on to hazard a guess as to the answer, promising to investigate today and either confirm or deny whether my guess was correct. Well, let's just say that it would behoove me in the future to verify my hunches before I open my virtual mouth, but what can I say? I was rattled to discover that unanswered question, and wanted to respond immediately.

Jennifer asked:

I set up an alert for a document folder in which I added about 10 people to the distribution. I realized after I set up the alert that I needed to modify the frequency setting from "immediately" to "daily summary". I know how to modify the alert for myself, but how do you modify the alert for the 10 people for which I originally set up the alert as well? I don't want to have to contact them individually and walk them through modifying their alerts manually.

Somewhat ironically, it was due to having investigated alerts functionality just yesterday that emboldened me to even hazard a guess as to the answer, and my answer was that I thought the process was the same to modify the settings for other users as it was for oneself. My thinking was that this was likely to be the case due to the fact that I was able to add a new recipient to an already existing alert (with the same existing settings) merely by adding their name to the Send Alert To field. As a result, it seemed a not unreasonable assumption that modifications made to that same alert would propagate to all users.

Not so, as I was to discover.

Turns out that, much to my chagrin and, I suspect, to Jennifer's as well, the only interaction with existing alerts that SharePoint out of the box allows for users (other than oneself) is to provide the ability to delete and recreate the alerts. Furthermore, the original alert needs to be manually deleted for every user on the distribution list (10 users in Jennifer's case) before creating the new, revised version, else those users will receive multiple alerts. To delete existing alerts, first follow the path to view User Alerts that I described yesterday and, once you select a given users' alerts, you'll see the Delete Selected Alerts option appear above the list of their alerts:

Needless to say, activating the checkbox for a given alert and clicking the Delete Selected Alerts hyperlink will (after an "are you sure?" prompt) remove the selected alert. Once you've deleted the alert for each individual recipient, you're in the clear to recreate the alert with your revised settings in place. You can either create a new alert from your My Settings/My Alerts area or via the Alert Me option associated with an individual document.

Finally, I'm duty-bound to mention that there is an easier way to manage alerts than the one provided out of the box, and it's called the Bamboo Alerts Administrator. Coincidentally, I mentioned this very product yesterday, and today I found myself using it in the course of my investigations.

I may very well devote tomorrow's entry to the Alerts Administrator now that it's come up twice in two days but, for now, I'll just say with the Alerts Administrator you can entirely dispense with the out of the box need to delete and recreate your alerts by way of modifying the alert. The Alerts Administrator will give you, at a glance, a listing of all the existing alerts on a given site, their current settings, and who's currently subscribed to those alerts:

Did you notice the edit icon associated with each instance of an alert? If you need to modify the alert frequency associated with a specific document or event (as was Jennifer's need), with the Alerts Administrator, it's as simple as clicking that edit icon and then resetting the frequency to suit your needs. With the Alerts Administrator, such modifications still need to be performed for each individual recipient but, unlike the out of the box experience, you're able to see all of the alerts for a site in a single view, and you no longer need to delete those alerts and start from scratch.

Sound like this functionality might ease your pain? If so, then by all means, I humbly encourage you to read more about the Bamboo Alerts Administrator.

How to View SharePoint User Alerts

2008-11-24T23:28:00Z

I recently received a question in response to my how to create & manage SharePoint alerts post that touched on an area of alerts management with which I was unfamiliar. Regular readers can probably guess what this means. Yes, it's time for another exciting installment of what's becoming an increasing regular feature, one which I'm sorely tempted to dub SharePoint Blank Investigates. (As an ardent admirer of hardboiled detective fiction and film noir, I ask that you please indulge me this harmless flight of fancy.)

Today's question comes from Nate, who asks:

How do I view alerts for a single document? I can see that I am in My Alerts. I can't see the other 4 people I added to be alerted to changes in this document. I added them in and changed the document name, but the adds as far as I can tell didn't stick. I have admin privileges.

After donning the requisite trench coat and fedora, as befits any self-respecting investigator, I began my investigation by attempting to duplicate Nate's experience in my own MOSS environment. I did so by adding a new name to the Send Alerts To field on an existing document via the Alert Me feature that's available in the dropdown menu associated with the document itself (inside the document library in which it resides):

Having added a new name to the distribution list of alert recipients for the document, I then clicked through the other options associated with the document (as pictured above) to see if any of those options displayed a list of alert recipients. None of them did, but I did end up duplicating Nate's experience when, after clicking on the Alert Me button again, I noticed that the name I had added earlier was no longer appearing in that field. The plot thickens.

So it was on to the second phase of my investigation, or, as I might as well officially call it, the Google phase. Google rarely lets me down, and today was no exception: Right there on page one of the search results (though, curiously, not as high as you might think) was a link to the often helpful Microsoft Office Online site, with an article entitled Manage alerts settings.

The steps involved in viewing user alerts as described in that particular Office Online article happen to refer to SPS 2003, however, and my environment uses the 2007 model. Thankfully, as a trained investigator, the steps described therein were more than sufficient to point me in the right direction. And so it was that, in my environment, the path to successfully answering Nate's question began, as so many SharePoint processes to, with the Site Settings option under the Site Actions dropdown menu:

On the Resulting Site Settings page, the next step towards successfully closing my investigation was to click the User alerts hyperlink under the Site Administration heading:

The resulting User Alerts page provided the answers Nate sought, albeit possibly not in as easy-to-use a manner as he might've hoped. The out of the box functionality of SharePoint provides users with the ability to see which alerts a given user is currently subscribed to within an individual site, via the following dropdown menu:

Did you note my use of the ever-popular phrase, "out of the box" above? Do you suspect that I, in my position as a card-carrying representative of Bamboo Solutions, might have an, ahem, solution in mind that could make Nate's life as a SharePoint admin easier? If so, I shall commend you on your perspicacity, hand the mic over to our product team, and allow them to introduce you to the Bamboo Alerts Administrator:

Manage SharePoint alerts across sites and Site Collections from one location. No more drilling down, site by site, to find and manage user alerts across sites or Site Collections.

The Bamboo Alerts Administrator provides SharePoint Administrators with the ability to create, edit, delete, group, and filter SharePoint alerts for all users within a single Web Application from one location. Create multiple alerts for one or more users in one step as well as create an alert for an Active Directory distribution group. SharePoint Administrators can access the Bamboo Alerts Administrator from anywhere in SharePoint from the Site Actions drop-down menu.

Thus endeth the investigation (and the product placement).

How to Edit or Delete a SharePoint Group

2008-11-21T17:04:00Z

Whoops, turns out I spoke too soon when I indicated yesterday that my groups-related posts were over ... there's still gold in them thar hills! This fact was brought home to me when I realized that, since I had created my test group on our corporate portal (as opposed to in a test area or in my My Site), it was now showing up as a "real" group in the Quick Launch on our portal. Which discovery naturally led to the question, "OK, I've created a group, now how the heck do I delete it?"

In the process of finding out how to delete my test group, I also realized that there's plenty of valuable information in terms of the care and feeding of a group that lurks within the group dropdown menus. Taking them from left to right, these options are included "under" the New, Actions, and Settings buttons on the dedicated People and Groups page for each group:

The dropdown options under the New button include Add Users and Add Group. Note, however that Add Users here doesn't mean add users to the group in question, but to the site in which the group exists. As well, New Group allows you to add a new group to the site:

The Actions button is where we get into the ability to directly interact with group members, and with the membership of the group whose page you're looking at. As you can see, the options here include: E-mail users, Call/Message Selected Users, and Remove Users from Group:

Those references to selected users are important. Via the checkbox associated with each member of the group, you'll need to manually select the user (or users) in the group that you wish to interact with in the manner selected, like so:

The final set of options, and the one which includes the ability to delete a group, are found in the Settings dropdown menu:

The first option, Group Settings, is largely a duplicate of the New Group creation screen, albeit filled in with all of your previously chosen settings ... and now including the elusive Delete button, which is found at the bottom right, just beneath the group permissions:

The View Group Permissions button will spawn a popup which explains that you should, "Use this page to view the permission assignments that this SharePoint group has in this site collection. In addition to the listed URLs, this group has access to any sites, lists, or items that inherit permissions from these URLs."

The Edit Group Quick Launch will render a page which will enable you to change which groups appear in the Quick Launch on the People and Groups page. It was seeing my test group among the "real" groups in the Quick Launch that set me on the path to discover how to delete the group.

Finally, the Set up Groups option will render a page which allows you to specify who can access your site, and also allows you to either create new groups on the fly or to use preexisting groups:

Funny how looking for one simple thing (e.g., how to delete a group) in SharePoint so often leads to a whole bunch of worthwhile new information, eh?

How to Avoid Multiple Login Prompts with Exchange Web Parts

2008-11-20T22:37:00Z

Following my groups-related diversions over the last few days, I'm back on SharePoint Blank Mailbag duty today. Kudos to Joe for asking a question that I'd been wondering myself, but hadn't yet taken the time to investigate on my own. Joe's question came in as a response to my Adding a My Calendar Web Part post, and relates to the annoying login prompt that both he and I see every time our respective My Sites attempt to load the My Calendar Web Part. Joe asks:

On my My Site, the first time I go there every day it asks me to authenticate for the calendar. Is there a way to let it remember my user name / password? When I go to a SharePoint page,it doesn't ask for a user name /password.

I spent some time researching this question via Google today, but before I reveal my findings, here's a fun, if slightly disconcerting fact: One of my own SharePoint Blank blogs was first in the search results that came back. Crazy, huh?

The good news is that it looks like I've found a solution for Joe. The solution I'm about to describe certainly proved to be a magic bullet to banish the login prompt on my own My Site, so I'm hopeful that the same will hold true for Joe and for anyone else who may be wondering how to banish the prompt from their experience.

Props to Matt Ranlett and Brendon Schwartz, whose Windows IT Pro article, Integrate SharePoint into your Exchange Environment offered the following insight and advice:

This behavior occurs because all the personalized Exchange Web Parts are basically Page Viewer Web Parts with some specific formatting applied. Finally, when you add the Exchange Web Parts to a SharePoint site, be sure to add your Exchange server's OWA URL to the trusted Local Intranet sites on the client machines. Doing so helps prevent multiple logon prompts.

Props are also due to Brett, who patiently walked me through the process of how I could add our Exchange server's OWA (which stands for Outlook Web Access, by the way) URL to the trusted Local Intranet sites on my machine. This was the process for me (running IE on Vista), so your own process may differ slightly, but just navigate to your Internet Options (aka, Internet Properties), choose the Security tab, select the Local intranet icon, and then click the Sites button:

On the resulting Local intranet popup, click the Advanced button:

The resulting popup will provide an input field to add your OWA URL. If you happen to know the URL you use to access Outlook Webmail, that's the one. If you don't know this URL, your Sys Admin should be able to provide it. Type your OWA URL into the provided input field, click Add, then Close:

With one final caveat, that should be all you need to do to rid yourself of the pesky login prompt. Here's the caveat: With "www" preceding my OWA URL in the input above, I was still getting the login prompt on my My Site, but once I removed the www from the URL, the login prompt was gone, baby, gone.

Troubleshooting an Error Message when Creating a New SharePoint Group

2008-11-19T22:03:00Z

Let's consider today's entry to be an addendum to my two-part look at how to create a new SharePoint group which concluded yesterday, shall we? As regular rears will no doubt recall, that episode ended in shame for me ... not with the creation of a new group as intended, but with an unsightly error message instead. Needless to say, I knew that I had to get to the bottom of that error message today before I could move on to another topic, and I'm happy to report that I have done just that.

As I noted yesterday, the error message that I received -which was, I should mention, the first error message I can recall ever having seen in my 6 months as a SharePoint user- was, "The security validation for this page has timed out." What I didn't mention or, in truth, take much note of myself in my disbelief at seeing an error message in the first place, was that there was another sentence in the error message which preceded the following not-at-all helpful to an end user codespeak:

at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bSendEmail) at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bSendEmail)

As it turned out, I should have paid closer attention to both sentences of the error message which were written in English (as opposed to the multiple lines written in Code) but, if I had done so, I probably wouldn't be writing this today since I'd likely have written off the error as being my fault in the first place. Which, by the way, it kind of was, since it was a timeout error, and since I was going through the process of creating the group while I was writing the blog entry, it's understandable that the operation would have timed out by the time I finally got around to hitting the Create button. Still, I submit that those unnecessary lines of code sent me into a bit of a panic, and that my comprehension of the second sentence in English was compromised as a result.

And so, when I revisited the scene of the crime with a cooler head earlier today, there was the sentence which would prove to be my salvation (and yes, when I say "there it was," I really mean, "there it was, where it had been all the time"):

Click Back in your Web browser, refresh the page, and try your operation again.

Guess which clause I had missed in my haste yesterday? It was the second one, "refresh the page." Guess how important that step is? Muy importante. As in, if you don't refresh the page, you're doomed to see the same error message for eternity. Yes, refreshing the page means that all of your carefully considered group creation decisions will be wiped clean and you'll have to start from scratch, but once you've done so, you (or your designated group/owner) will be be the proud owner of a new SharePoint group, like this one:

And that sure beats staring at an error message for eternity, doesn't it?

Create a New SharePoint Group, Part 2 of 2

2008-11-18T21:37:00Z

When we left off yesterday, we had just arrived at the (create a) New Group page, and were on the very cusp of beginning to make the series of decisions required to create a new SharePoint group. Join me today as we step through those decisions together, and emerge victorious with the creation of a new SharePoint group. Please hold your applause until the end.

There are five decisions to be made in total, and in the images I've provided below, I'm depicting the default appearance of each field, which is why some fields will be blank. As with most SharePoint "create" actions, the first decision is simply assigning a name and description. In the case of a new group, the description is labeled as an About Me description. Despite that somewhat misleading nomenclature, however, the "me" in question refers to the group itself, and not the creator of the group:

Next on the hit parade is the Owner field. There can only be one owner, but the owner needn't be an individual - it can be another group. As I learned from the instructors at Mindsharp, the best practice recommendation in this case is to not leave yourself as the owner (which is the default behavior, as shown below), but to create a group for this purpose. This way, at least one other person has ownership rights ... just in case, y'know, you were to get hit by a bus or something. Note that next to the input field, you're provided with the standard Check Names and Browse options which should be familiar to most Outlook users:

Group Settings is the next decision you have to make, and this one is a twofer. The first decision has to do with who can see the members of this group, and your choices are Group Members, or Everyone, with the choices presented as radio buttons. (Note to self: Hey, look at that! Now go update Friday's post in which I was speculating about this very thing.) The second decision here determines who has the rights to edit the group's membership: only the Group Owner, or all Group Members?:

Next up is the Membership Requests decision-making process. The first decision is whether to permit potential new group members to request to join (or existing group members to request to leave) the group. The second decision is whether to auto-accept these requests or not. Note that enabling auto-accept immediately and automatically grants all such requests ... and grants new members the same permissions assigned to existing group members. Requests are sent to the email address provided in the membership requests input field and, as you can see, by default the email address provided is that of the group creator. Naturally, this field becomes configurable should you choose Yes for either of the requests options:

The final decision in the group creation process is assigning permissions to group members. The permissions you choose will apply to all group members, and you'll make your choice by choosing to mark one of the available checkboxes, ranging in permissions from Full Control (basically, the King) all the way down to View Only (basically, the peasant), and everything in between. Surprisingly, I seem to be able to select more than one checkbox in my MOSS environment, but presumably only one such selection can be honored:

The view site permission assignments hyperlink pictured above will take you to the Site Permissions page, which will show a list of groups and users with access to the site in which you're creating the new group, and their current level of permissions.

And wouldn't you know it? For my hubris in announcing that we would be emerging victorious with the creation of a new SharePoint group today, I have been punished with the following error message: "The security validation for this page has timed out."

Oh, SharePoint, why must you smite me so?

Create a New SharePoint Group, Part 1 of 2

2008-11-17T22:00:00Z

Friday's blog topic, detailing where to find and modify existing groups in a SharePoint site caused me to go back and review a previous entry wherein I addressed SharePoint groups. Which, in turn, caused me to realize that I might have misspoken in that previous entry when I said, based on what we'll charitably call a not entirely accurate assumption, that SharePoint group creation wasn't likely to apply to most end users.

What was the inaccurate assumption which led to such a gaffe? Well, it happened because I didn't have permissions to create a group within the main Bamboo corporate portal, and I (foolishly) extrapolated from there that I must not have permissions to create groups throughout our site collection, with the sole exception being my My Site. Yes, it's kind of embarrassing to admit this but, hey, I figure it's all part of "growing up" in public. Also, what's a mistake but an opportunity to learn, right?

Needless to say, I've just come to the realization that I actually do have the ability to create a new group within our portal ... just not on the top site.

So, might you be able to do the same within your portal?

Maybe.

The first thing you'll need to determine is whether you have the requisite permissions to create a new group on the site where you hope to do so. For example, I lack the necessary permissions to create a new group at the top level of our portal, but what I've now discovered (after having first thinking it through, which clearly I had failed to do when preparing that earlier column) is that I do have access to create new groups in my team's site, which exists as a subsite within the Bamboo corporate portal.

Having learned my lesson regarding assumptions, I did the research this time and discovered that only users with full control to a site possess the ability to create groups. For information on pretty much all of your SharePoint permissions-related needs, I recommend checking out this Microsoft Office Online page on SharePoint permission levels and their associated permissions.

So, from within a site where you've got full control, and where you wish to create your new group, you begin by selecting the trusty Site Settings menu option under the Site Actions dropdown:

Hint: If your Site Actions dropdown doesn't have a Site Settings menu item, you lack the necessary permissions to create a group on that particular site.

On the resulting Site Settings page, select the People and groups hyperlink under the Users and Permissions heading:

The resulting page will be the People and Groups page and, as mentioned on Friday, you'll notice options to display lists of both existing people and existing groups in the Quick Launch. To create a new group within your site, select one of the existing groups in your Quick Launch and simply click the New dropdown button, which (in my MOSS environment), only has one option, New Group:

(Note: You may also create a new group from within the context of one of the All People listings in the Quick Launch bar. In this case, the New dropdown has two menu items, with Add Users appearing in addition to New Group.)

Clicking that New Group menu item will render the New Group page, where you'll be presented with a series of decisions to make regarding your new group and its membership. Tune in tomorrow when we'll walk through those individual selections step by step, and we shall emerge victorious, having created a new SharePoint group.

The SharePoint ‘People and Groups' Page

2008-11-14T22:55:00Z

Continuing my efforts to perform the due diligence necessary to answer my SharePoint Blank mailbag (hmm, maybe I should start incorporating that into the title for these posts?), today's question came in from kayroxx in response to an entry on SharePoint group creation:

So how do you actually look into a SharePoint group to see who is in that particular group? Where do you even go to see that group at all?

It's been a heck of a week for me, so I'm going to cut myself a little bit of slack for the fact that it took me an embarrassing amount of time to arrive at the answer to kayroxx's question. Why was it embarrassing? Well, let's just say that, by the time I arrived at the answer, I realized that it was something I had actually learned in Mindsharp's Power End User summit months ago ... but since it's not something I've had cause to use in my day-to-day operations (and, thus, haven't yet documented here), I'd forgotten that I actually knew the answer. D'oh!

So, in my MOSS environment (which, by the way, was also the environment used in the aforementioned Mindsharp course), the path to ultimately answering kayroxx's question began by navigating to our team portal, i.e., a site to which I knew that I had a reasonable number of permissions, and clicking the Site Settings menu option on the Site Actions dropdown:

Next, I selected the People and groups hyperlink under the Users and Permissions heading:

Having clicked that hyperlink, the resulting People and Groups page is a veritable one-stop shop for all of the individual users, and all of the existing groups, on the site. Conveniently, they appear listed under All Groups and All People links in the Quick Launch, and clicking the appropriate links will expand that section within the Quick Launch. Selecting an individual group will display the members of that group in the page.

Well, doing so will display the group members with one caveat: A little clicking around on the Groups links within our corporate portal quickly revealed to me that it's not permitted for just anyone to view the memberships of all groups, as permissions are required in order to do so. My (not entirely scientific but, I think, reasonably conclusive) research indicates that you must be a member of a given group in order for to be able to view the members of said group and their permissions within the group. Unless you are a member of a given group, you will only be able to see the members of a group if the group creator chose to make that group's membership visible to Everyone (i.e., all site users), as opposed to being visible to Group Members only.

Unfortunately, I don't think there's a handy way to see, at a glance, all groups to which you're a member, but if I should learn of one, I'll certainly let you know. Of course, if you know of such a feature, by all means, do feel free to lay that sweet, sweet knowledge on me. Cheers.

Editing Columns in a SharePoint Document Library Redux

2008-11-13T22:01:00Z

One of the unanticipated effects of Mark Miller's recent (and much appreciated) plugging of SharePoint Blank over in EndUserSharePoint has been the sharp uptick in the number of questions that I've been fielding in the comments section of older blog entries. Unfortunately, quite a few of these questions rolled in over the past few days while I was, far more unfortunately, out of the office due to a death in the family. I'm honored to be asked these types of questions, especially since there's an implied assumption that I might actually know the answers. Sometimes I do know the answers, but I'm a card-carrying end user whose SharePoint learning is a day-to-day process, so I generally don't know the answer off the top of my head. I am, however, more than happy to seek out the answer for you, and the fact that doing so also increases my own SharePoint knowledge is the icing on the cake. Thus, I'll be dedicating the next few days to playing catch-up on my backlog of questions, diligently researching the questions and, to the best of my ability, documenting my findings here.

Two questions came in over the last few days on my Editing Columns in a SharePoint Document Library post from early September, so it only seems right that I mark my return to the blog with a "two-for-one special" by tackling them both today.

First up, Neevarp asks:

I tried to create a column for a document library and it sets itself to be a Read Only column, I am unable to change the type. How can I cange its type to a non read only type so that users can update the column information?

I didn't recall being presented with an option between read only or not when I created a custom column so, following my own footsteps, I began looking into this by creating a new column in an existing document library. Sure enough, in my (MOSS) environment, there's no mention of read only status (or not) when creating a column but, in my environment, the default is for column data to be editable, as opposed to being read only. The plot thickens, no? Off a-Googling I went. From what I've discovered, the experience in my environment appears to be the norm, in that custom columns should be editable unless explicit steps have been taken to make them not so. I arrived at this decision after I discovered a discussion on eggheadcafe which explains how a Sys Admin might go about making column data read only to end users. Check it out, and if I'm misinterpreting anything, please correct me in the comments but, from what I tell, it sounds like a conscious decision has been made by your Sys Admin to force custom column data to be read only. You might wish to consult your Administrator and inquire as to why this decision was made and, as appropriate, respectfully request that the policy be revisited.

Next up, we have Anton Tomassen, who asks:

Is it possible to edit the "created by" column in SharePoint? I will populate a list with data but the created by column then has my details in it. I want it to have unique usernames of the people in my AD in order that I can set the view only to show the row in the list that belongs to the logged on user.

Since I didn't have a Created by column in any of my existing document libraries (the Modified by column is the standard at Bamboo), I began my investigation by creating a new view for an existing library, and adding a Created by column. Alas, when clicking the dropdown menu associated with the newly created column, the only available options involved ordering and filtering:

So it was off to Google once more and, in this case, props must go to Sowmyan's SharePoint Developer Blog for the post entitled, Can we update the values of "Created By", "Modified By" columns in SharePoint lists? In this post, Sowmyan answers, in part, "Of course, you can. Created By & Modified By columns are 'Person or Group' type columns. In SharePoint all the lists have these columns by default. You can't update the values of these columns from UI. But, you can do it through SharePoint APIs." Best of all, Sowmyan helpfully provides a .NET code snippet which will make it possible to update these values. Needless to say, this is hardly end user-level functionality, but I'd recommend that you consider directing your Sys Admin to Sowmyan's code snippet and asking nicely if this functionality is something that might be incorporated in your site.

I hope these answers were helpful, and that you'll both be able to leverage my findings towards achieving your goals. If you're so inclined, please report back and let me know how everything worked out.

Working with the My SharePoint Sites Web Part

2008-11-07T22:08:00Z

Before we pick up with the sequel to yesterday's post on how to add a My SharePoint Sites Web Part to your site, I'd like to acknowledge the mighty Mark Miller of EndUserSharePoint.com for his gentle suggestion that I mention that this particular Web Part is a MOSS-only feature. Since I'm working in a MOSS environment, and since pretty much everything in SharePoint is new to me, I sometimes forget to make the MOSS/WSS distinction (when applicable). Mark's comment on yesterday's post served as ample reminder that I need to bear this fact in mind when I'm documenting my adventures in SharePoint. Cheers, Mark.

When we left off yesterday, I had successfully added a My SharePoint Sites Web Part to my My Site:

I have since confirmed that, per Microsoft, "The SharePoint Sites Web Part automatically displays a list of five sites of which you are a member." Upon seeing the default tabs that had automatically been chosen for me, I realized straightaway that there were some changes that I wanted to make to the appearance of the Web Part. To wit, I wanted to delete the test tab since it linked to outdated test content, and I wanted to add a new tab which would link to my team's site on the portal.

Deleting the unnecessary test tab proved to be a simple two-step process. As it turns out, the navigational tabs in the My SharePoint Sites Web Part offer dropdown menus which feature two options: Hide, and Delete:

Since I knew I wouldn't need that test tab for any reason going forward, it was the Delete option that I selected. Take note: Deletion is immediate. There is no "are you sure?" messaging or the like here, and as soon as you click Delete, your site will immediately refresh with the revised version of the Web Part (i.e., minus the deleted tab).

Adding a new site tab to the My SharePoint Sites Web Part is almost as easy as deleting one though, so even if you mistakenly delete a tab, it's hardly the end of the world. First, select the dropdown menu associated with the Sites tab which appears at the extreme left of your navigational tabs, and you'll see that New Site Tab is one of the two available menu items. Click that option to begin creating your new site tab:

Upon clicking the New Site Tab button, your site will refresh with the Create a new site tab UI:

By default, the Select Sites from Membership list radio button option is selected, and the first item in the memberships list dropdown menu will appear highlighted. Since the first item in my list wasn't the site that I wanted, I scrolled through the list until I found the desired entry, the Online Operations listing pictured above. As you can see, however, you're not limited to the items which automatically appear in your Membership list menu - you also have the option of manually entering the Site URL and Site Name to create your new tab.

Since I found the site I wanted in my Membership list though, all I needed to do to create my new tab was to click the Create button, and voila, I was the master of my (revised, tab) domain!:

Adding a My SharePoint Sites Web Part

2008-11-06T22:02:00Z

As I mentioned in yesterday's post, it was while getting started with Mindsharp's CBT courseware for end users that I discovered the existence of the My SharePoint Sites Web Part. I might add that I knew straightaway that this was a Web Part that I wanted for my My Site. As promised, today's post is going to provide a step-by-step guide to adding the My SharePoint Sites Web Part to your site.

By way of a reminder, what this Web Part does is aggregate any and all content that you have authored/uploaded (from across multiple sites within your site collection), and presents that content to you in a cleanly designed Web Part which uses a tabbed user interface. I dig it the most, and I think you will too.

So how can you get a My SharePoint Sites Web Part of your very own, and be the envy of all your colleagues? It's simple. First, from within the site where you want to create the Web Part (I added it to my My Site which, come to think of it, may in fact be the most logical location for this Web Part), select the Edit Page menu option from the Site Actions dropdown button:

On the resulting Edit Mode display of your page, choose the Zone where you'd like to add the Web Part. I'd recommend adding it to whichever Zone provides you the most width, since that will give you room to grow in terms of adding tabs for multiple sites. Once you've chosen a Zone, click the Add a Web Part bar in that Zone:

In the resulting Add Web Parts popup, locate My SharePoint Sites listing, noting that you may need to scroll and/or expand certain areas to find it. I found it under the Content Rollup heading on our portal. Having located it within the list, click the associated checkbox for the Web Part:

Once you've placed a check in the checkbox, and clicked the Add button at the bottom right of the popup, your page will refresh (in Edit Mode) with your new My SharePoint Sites Web Part in place. I suspect that, as was my experience, you'll find several default site tabs will appear automatically, with the tab for the site on which you've added the Web Part preselected:

Right off the bat, I saw a couple of changes that I wanted to make. Specifically, those changes involved removing the test tab, and adding a tab for my team's site.

Tune in tomorrow, and I'll give you the full scoop on how to accomplish those very tasks.