Filtering a Data View Web Part to Current User

When you begin using data view web parts (aka data form web parts) to display information on a sharepoint webpage, you will find that filtering is rather easy. After you insert a data view, you should see a small '<' symbol (MSFT calls it a chevron) off to the right of your new data view webpart. If you click it, you can see that the first thing they let you click is to Filter. When you do, you can choose the first dropdown to be any column; but to filter it to the current user, you need to pick a Person/Group column that you have created. The middle dropdown should be "Equals". The third dropdown, you should be able to scroll to the VERY bottom and find something called "[Current User]". This will filter the webpart to only show you items where your username is in that person/group column. Mine looks like this:

Pretty simple, huh? Well, there's one small kicker to this: this works right IF you are only using a single list. If you follow the instructions of Laura Rogers or other SharePoint gurus and create a linked data source (joining the information from 2 different lists with a common column), then this filter will not work. It will actually change the place in the "code" where the filtering happens and it just won't work. The way to fix this is to open up the page in Split or Code view and you'll have to copy-paste something from here into a specific part (don't worry, I'll show you where). The piece you need to copy to your clipboard is this:

"&lt;View&gt;&lt;Query&gt;&lt;Where&gt;&lt;Eq&gt;&lt;FieldRef Name="YOURCOLUMNNAME"/&gt;&lt;Value Type="Integer"&gt;&lt;UserID/&gt;&lt;/Value&gt;&lt;/Eq&gt;&lt;/Where&gt;&lt;/Query&gt;&lt;/View&gt;"

What this really looks like is this:
"<View>
  <Query>
   <Where>
    <Eq>
     <FieldRef Name="YOURCOLUMNNAME"/>
      <Value Type="Integer">
       <UserID/>
      </Value>
    </Eq>
   </Where>
  </Query>
 </View>"
This is the dreaded CAML - a markup language used to get information from sharepoint lists like SQL will get information from SQL tables. What it means is that it needs to check the Field "YOURCOLUMNNAME" (which you will need to replace with the name of your person/group column that you want to filter by) and use the "UserID" integer (aka your ID number from sharepoint) to only get the ones where the ID number in that column matches yours. Where you will need to place this code, look toward the top of the code for your data view webpart and look for two things: 1) the words "SharePoint:AggregateDataSource" and several "<asp:Parameter"s. 2) just below the Aggregate data source and some of the parameters, you should see "SharePoint:SPDataSource" and toward the right you will find the phrase SelectCommand = "&lt;View&gt;&lt;/View&gt;" or something super close to that. Replace everything in quotes for the SelectCommand with the stuff from above. Be sure to rename the YOURCOLUMNNAME with the actual name of your column. This will filter that data source automagically for you. Hope that helps and doesn't increase brain fog.

Problems with SharePoint Anonymous Access

Out of the box, anonymous access is a pretty cool idea but breaks several things.  Just to help those who may think about anonymous access (defined as users that don't login at all on something), here is a list of things that are altered:

1. Workflows - worfklows that are set to automatically run when you create a new item will break if you turn on anonymous access.  Not only will the workflow not run, but here's what will typically happen:  a user will click "new", fill out your sharepoint form, and then they click OK.  When they do, they get an error message saying that there is a Server Out of Memory and think that something went wrong, so they try to fill it out again.  What the anonymous user DOESN'T know is that their information WAS submitted but the workflow didn't run.  The error message that they saw was in regard to the workflow.  If this happens, the primary way people are fixing it is to create a new list as a copy of the current list, copy all the data over from the old list to the new one, and delete the old list.  You CANNOT just delete the workflow...certain pieces of the workflow are not deleted when you delete a workflow and THOSE are the things that are breaking the workflow.  Some people have figured out another solution but this seems to be the main way to fix it.

2. Surveys - SharePoint surveys are already a very limited template but they get further limited with anonymous access in that you cannot use branching logic, page breaks, or limiting people to only filling out a survey 1 time.  This doesn't mean it's not useful, it's just very limited in its applications.

3. Libraries - Anonymous users are not meant to access libraries, so just get that out of your head now.  Technically, you can use a URL hack to allow them access but they won't be able to add and upload documents or anything.

4. InfoPath Forms - anonymous users can't access infopath forms unless you have forms-based authentication (which supplies a default username/password if none exists when you turn on anonymous access).

5. Edit or Read Your Own - these settings typically only allow someone to see or edit their own stuff...well, this is impossible with anonymous users because there's no way to tell one anonymous user from another and, thus, it will not show anything for anonymous users.  This can sometimes be a benefit and other times a problem.

That's all for now; if you find anything else, please let me know and I'll throw it up here.

Input Mask in InfoPath fields - entering phone numbers and emails

If you have a field in InfoPath where people are supposed to put in their email addresses or a website or phone number - you may have asked whether or not we can double-check that they put it in in a certain way (e.g. a phone number has to be entered in the format (123)555-7899.  There is a way to make this happen - even in browser forms - using something called Regular Expressions.  You won't see the phrase "regular expression" in InfoPath but you will see something like "matches pattern" or "does not match pattern" - which are regular expressions.  Here's the basic way they work:
Using either Conditional Formatting or Data Validation in your InfoPath form, you should have [Field1] [Does not match pattern] [some pattern goes here] - and the action or tooltip should either disable/hide the control or have a message stating something like "Please type your information in the correct format".  Patterns use the following building blocks:

0. If you want to have a symbol for any letter:  \p{L}
1. If you want to have a symbol for any character (letter, number, or symbol):  . (yes, that's a period)
2. If you want to have a symbol for any digit:  \d
3. If you want to use a period, parenthesis, or dash symbol:  \. or \( or \-
4. If you want one of the above to be used a certain number of times, you can use an *, a +, or a ? but they must go AFTER the thing you want to be only used a certain number of times.  * = 0 or more of that thing (e.g. \d* means either no digit up to a huge number - as big as you want).  + = at least 1 or more of that thing (e.g. \d+ means at least 1 digit but can get to be as big as you want).  ? = 0 or 1 of that thing (e.g. \d? means either a single digit or nothing).

So, how does this help you with making people enter phone numbers or emails correctly?  Here's what the patterns should look like:
(for phone numbers):  \d?\(\d\d\d\)\d\d\d\-\d\d\d\d
Notice how there's that optional digit at the beginning for the USA country code?  Obviously, international numbers will be a bit more complicated, but this will make people type in their phone numbers as 1(123)456-7899 or (123)456-7899 - depending on if they want a country code.

For email addresses:
.+@.+\.\p{L}\p{L}\p{L}?\p{L}?

• See the first period means at least 1 character or more but can be any size.  This works great to make sure they at least type something but it could be anything like jdoe or bob or super_director.  
• The @ symbol doesn't need anything special so you can just type it.
• The \p{L}+ means at least 1 character but as many as you need to type your domain like gmail or aol or hotmail or yourcompany
• The period needs that slash in front of it because periods do other things in regular expressions
• After the period, there are two \p{L} because almost every ending to an email will have at least 2 letters (e.g. .us, .com, .net, .info, .gov, .edu, .org, etc.)
• The last two \p{L}'s are followed by a question mark to mean that they are optional but that the most you can have is 4 letters.

So, for something else to try, why not see if you can make a pattern that checks to see if they type a web address correctly (as in, they have to type http(optional 's' here)://(www or some other word).something.something_up_to_4_letters (e.g. http://www.google.com).  If you want more, look up Regular Expressions or Regex to see what you can accomplish!

RELATED POST:  I have another post about this in regard to limiting the number of characters people are able to type in MULTI-line fields (if you have a regular textbox, there's an easy option to limit the number of characters on the Display tab...but NOT so if you choose to make that textbox multi-line):  Limit number characters in multi-lines of text InfoPath fields