http://sharepointmagic.wordpress.com/2011/09/07/sharepoint-2011-conference-connections/

Edit: If you have news of any other events, please post them in the comments and I’ll be sure to update this post and Mark will probably update his as well.

Thanks!

First, to do this, you’ll need PowerShell v2 (or better). Version 2 contains the -File cmdlet, which lets you run a script (*.ps1 file) from a powershell prompt. If you run Windows Server 2008 R2, then you have PowerShell v2. Otherwise, you may need to download it.

 Second, you’ll need to set the execution policy. Assuming you are on a dev box (Visual Studio and all), you can set the execution policy to unrestricted, via set-executionpolicy unrestricted. To check your current policy, use get-executionpolicy.

Third, keep in mind Visual Studio is 32-bit, while powershell has both, 32 and 64-bit versions with their own policies. The 32-bit VS should call the 32-bit version of PowerShell. Here is a screenshot showing the different powershell prompts and different execution policies.

Fourth, here is my script that will render arguments to the console. Yep, that’s all it needs to do.

Finally, the passing of parameters from Visual Studio is quirky. When I used “($ProjectDir)” “($ProjectDir)\bin”  Visual Studio passed that to PowerShell as one parameter. When I added a space  “($ProjectDir) ” “($ProjectDir)\bin”  Visual Studio passed that as 2 parameters. Here are the screenshots.

Finally, here is the script that will make the cab file. It’s all about making the ddf file. Enjoy!!

Note: If changing the execution policy at a powershell prompt does not seem to work (ie, Visual Studio still returns an error such as:

------ Rebuild All started: Project: SPProject, Configuration: Debug Any CPU ------

Compile complete -- 0 errors, 1 warnings
  File C:\MakeHCCab.ps1 cannot be loaded because the execution of scripts is disabled
  on this system. Please see "get-help about_signing" for more details.
      + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordE
     xception
      + FullyQualifiedErrorId : RuntimeException

 then you can use

powershell -command "set-executionpolicy unrestricted" 

in the prebuild event before the -file command.

InfoPath Form Version Dialog

Well, if you need to keep track of the version number for your form, you can make it easy on yourself and others by adding a small field at the bottom of your form. Then in the default value of this field, insert the formula

substring-before(substring-after(processing-instruction()[local-name(.)
  = "mso-infoPathSolution"], 'solutionVersion="'), '"')

Formula for Displaying the version number of a form

Here is a simple screenshot that shows the control

InfoPath Form Version Control

And here is what it renders like (screen clipped a lot):

InfoPath version control rendered in InfoPath Forms Services

I hope this helps you keep track of InfoPath forms version numbers. I know it will me.

1. Custom Field Controls
2. Custom Forms (Edit, Display, New Forms)
3. Custom Event Handlers

I’m going to cover each of these in seperate articles. They cannot be adequately covered in one blog post. Well, they probably can, but I cannot adequately cover them all at once!

To start, I’ll offer just an overview of each before writing up posts for each of them.

Custom Field Controls

These are the truest form of Field Level Security. No matter where the field is used, the control will apply the same security rules — whatever those may be, as this is a custom control you’ll write your own rules. This can be good, or bad. Imagine designing this control to work with multiple sites, site collections, even web applications. How do you design it to function properly across the entire farm?  Answer: you’ll have to wait until that blog post is written! Another issue with using custom field controls is that you have to write a custom control for each type that you’d like to have secured — types being single line of text, multiple lines of text, dates, booleans, etc.

Custom Forms

(Note: I’m focusing on the Edit Form)
The custom edit form is not one that is designed with SharePoint Designer. While you could design one-offs this way, we’re interested in scalable and repeatable designs. The custom edit form that we’re interested in designing is one that can easily be packaged and deployed. This method is more flexible, but isn’t the truest field level security. We’re going to look into custom templates.  This allows us to use a single control (ascx file) that works for multiple forms.  Just point your content type to this control, and viola! A secured edit form!

Also, one could create a custom form that is an application page, deploy it, and then point a content type to that form. TO do so, just update the Form’s <Form> xml node within the Content Type. While that provides a lot of flexibility in the code, ultimately, I’m not looking to replace SharePoint functionality here. I’m really just trying to get Field Level Security implemented.

Custom Event Handlers

Custom Event Handlers are my least favorite method of the three. On the plus side, they are by far the easiest to grasp and implement, they work for any content type, and they are the most familiar to SharePoint developers. So why are they my least favorite? Because they don’t provide any forewarning to the user that security rules exist. The user can interact with the control and seemingly make edits. But when they click the Save button, the security rules get applied, and suddenly the user is told they don’t have the priviledges to make their changes. Imagine making changes to a Word document or Excel spreadsheet, getting all the right info into it, and then when the user saves it, the application throws a message and discards the changes.  Not a great approach, IMO. Another negative is the hassle of dealing with Before and After Properties. Sure, those work for list items in most cases. But what about document libraries?  Document libraries require special attention because the ItemAdding and ItemAdded method must both be used, since AfterProperties aren’t available in ItemAdding while BeforeProperties aren’t available in ItemAdded.

Also, how do you handle the case where the user can update FieldA but not FieldB? Do you keep the changes for FieldA and not FieldB? How do you inform the userFieldA was indeed changed, but FieldB was not? Keep in mind, you can display a message if and when you use the Cancel. If you don’t Cancel the change, you can’t display the message. So you can discard all changes (in this case to A and B) and let the user know. Or, you can accept the change to A and not B, but the user won’t explicitly be told.

I’d love to hear your thoughts on these three options. Another type of workaround would be workflow, but that’s a lot of hassle.

I’ll update this post with the links that will be in my presentation.

Information Worker Virtual Machine:

http://go.microsoft.com/?linkid=9728417

There are about 20 videos here on Channel 9 for developers:

http://channel9.msdn.com/learn/courses/SharePoint2010Developer

More to come…

Here is a screenshot of the code for easier reading.

Script to display all SharePoint features

Here is the code so that you can copy/paste.

clear-host;
Add-PSSnapin Microsoft.SharePoint.Powershell
write-host "Farm scoped features"

# This will display all Farm scoped features
#Get-SPFeature -Farm 

# This will display a specific Farm scoped feature if it exists
Get-SPFeature -Farm | where { $_.Id -eq "319d8f70-eb3a-4b44-9c79-2087a87799d6" }

write-host 

foreach ($webapp in get-spwebapplication) {

  write-host "Web Application " $webapp.url  

  # All WebApplication scoped features
  #Get-SPFeature -WebApplication $webapp.url 

  # specific WebApplication scoped feature if it exists
  Get-SPFeature -WebApplication $webapp.url | where { $_.Id -eq "0ea1c3b6-6ac0-44aa-9f3f-05e8dbe6d70b" }
  write-host 

  foreach ($site in $webapp.sites) {

    write-host "Site Collection " $site.url 

    # All SiteCollection scoped features
    #Get-SPFeature -Site $site.url 

    #specific SiteCollection scoped feature if it exists
    Get-SPFeature -Site $site.url | where { $_.Id -eq "7094bd89-2cfe-490a-8c7e-fbace37b4a34" }

    write-host 

    foreach ($web in $site.AllWebs) {

      write-host "Web " $web.url 

      # All Web scoped features
      #Get-SPFeature -Web $web 

      # Specific web scoped feature if it exists
      Get-SPFeature -Web $web | where { $_.Id -eq "00bfea71-1e1d-4562-b56a-f05371bb0115" }

      write-host
    }
  }
}
write-host "Done"

2. Insert your data. In the photo below, I demonstrate creating a term called USA. Under that, I create the term Alabama. Under that, 4 cities. Then under USA, a term called Alaska. The point is that the we have a hierarchy. Using the import file, we can go 7 layers deep.

3. Save the file, head back into the Term Store Management Tool, select/create a group, and Import the file.

First, be sure to have configured a Managed Metadata Service and have a termset to use.
Second, go to a site collection and configure a Managed Metedata field to use that termset. 

Create a list item and assign it a value for the Managed Metedata field. Take note of the value.

Now locate the Timer Jobs in Central Admin > Monitoring. Scroll down or page over to the Taxonomy Update Scheduler jobs.  I disabled all of the Taxonomy jobs for this demo.

Here are a list of my Web Applications. You can see how each Web App (image below) has a Taxonomy Update Scheduler job (image above) assigned to it.

Now go into your Term Store Management Tool (via /_layouts/termstoremanager.aspx”>http://<siteurl>/_layouts/termstoremanager.aspx ) and update the value.

The original value was Houston.

The updated value is Houston, Tejas.

Back on the site, it still shows the old value, Houston.

If we go into Central Administration and open up the Taxonomy Update Scheduler job, we can Enable it. Then we can Run Now.

After a few seconds, the Taxonomy Update Scheduler Timer Job will have completed. And after F5’ing our list view, we’ll see the updated value.

So that’s how changes to the MMS are pushed down to content.

Background:
I’ve created a Team Site (can be any template of course) on my demo portal.
I’ve created a Managed Metadata Service in Central Admin.
I’ve wired up my demo portal Web App and my MMS Service App.
I’ve imported a Country-State-City taxonomy termset.
I’ve created a custom list (CustomListA) in my demo portal.
I’ve added a Managed Metadata field to my list and configured it to use my Country-State-City taxonomy termset.
I’ve added two items to my CustomListA. And I’ve chosen USA:Alabama:Huntsville as my item locatoin for each item.

I’ve used PowerShell to dump out my CustomListA xml.

Let’s take a look at how the data is stored. First, you can easily see the ows_Location field pointing to “12;Hunstville”. The 12 comes from the fact that Huntsville is the 12th Managed Metadata term to be used in my Site Collection.  If I had only used 3 others, then Huntsville would be #4. I think you get the idea here. Note: I’m not sure why it needs to keep the 12 when another attribute contains the GUID — notice the 63371559-… after the Huntsville in ows_LocationTaxHTField0 field [Line 7]. But it is what it is.

After looking over the CustomListA XML file, I then used PowerShell to render my TaxonomyHiddenList. This list is what ties all other lists in it’s site collection to the Managed Metadata Service or TermStore. If you scroll down to line 656, you’ll see ows_IdForTerm=63371559… This is the same value in Line 7 of the CustomListA xml file. This GUID is our link.

For what it’s worth, here are the powershell scripts used to create these XML files. First, the script to create out custom list xml file.

Second, the script to create our TaxonomyHiddenList xml file.