I’ve been working on some InfoPath forms this week in MOSS in an FBA environment and learned, when I went to deploy the forms to a production environment with an FBA zone that the username() function function does not work.  I was using it to generate unique file names.

Well, that function doesn’t work in an FBA environment (at least, not out of the box).  And, upon reflection, using username in the way I had planned wouldn’t have guaranteed a unique file name in any event.

My solution was to use the now() function and a rule that fires on loading of the form.  I assign the file name to data element when it’s blank:

The advantage of this approach is that the file name is set only once.  (I don’t show it in the screen shot, but put a condition on the rule to only fire when “myFilename” is blank).  I used to set the file name at the data source level.  Typically, I would do something (bad) like this:

The problem with that is that if user A opens the form on Monday and the user B changes it on Tuesday, you’ll end up with two different forms since two different users saved it with different user names.

So, as annoying as FBA can be in general and with InfoPath in particular, it made me re-think a small but really important technical detail and approach that I wouldn’t have done otherwise!

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

This is another post in my on-going series on how to use jQuery with SharePoint.
If you want to learn more about jQuery, I highly recommend: jQuery in Action by Bear Bibeault and Yehuda Katz.

One of the first things I thought, once I started to play around with jQuery, was whether we could use it to secure a SharePoint view.  The answer is “no” (or at least, I’m not claiming it’s possible).  However, it is certainly possible to make it difficult for people to see a particular view. 

I started with my sandbox environment when working on this.  I wrote about that environment here: Quick and Easy: Create Your Own jQuery Sandbox for SharePoint.  

To “secure” a view, follow these steps:

1. Create a view you want to secure.  I did that and called it “Secured View”.
   
   This is what it looks like when it’s not “secured”:
   
    
   
2. Add a content editor web part to the view’s page using the trick described in the sandbox article (i.e. add “PageView=Shared&ToolPaneView=2” to the URL).
3. Figure out  your SharePoint _spUserId by following these crazy steps, believe or not:
   1. Log into your SharePoint environment.
   2. In the web browser’s address field, type: “javascript:alert(_spUserId”).
   3. Record the result (it’s “13” in my case).
      
      
4. Add the following javascript to your CEWP in code view:
   

   <script type="text/javascript" src="../../jQuery%20Library/jquery-1.3.2.min.js"> </script> <script type="text/javascript"> $(function() { alert(_spUserId); var theSecuredView = $('iframe[FilterLink*=Secured%20View]'); if ((theSecuredView.length > 0) && (_spUserId == 13)) $('iframe[FilterLink*=Secured%20View]').parent().parent().parent().html("<tr bgcolor=red><td>No view for you!</td></tr>"); }); </script>

I’ve included that alert(_spUserId) line in there to demonstrate how this is not really a “securing” a view, but simply making it more difficult to see.  More on that in a moment.

Basically, jQuery is looking for an iFrame on the page who has an attribute that contains “Secured%20View” in its value.   Once it finds it, we check to see if the current user is “13”.  If it is, we walk up the DOM to a <TR> tag (which I figured out by viewing source and tracing it) and then replacing that TR tag with my message. I really don’t know how robust this is (I’m very suspicious, in fact), but it worked in my sandbox.  If I find a better way, I’ll blog about it. This is the result:

I click the OK button and the data is replaced with a big red message:

As you can tell, the way I’ve implement this “security” solution is to allow the web part to render itself.  After it finishes, I overwrite its content with my “No view for you!” message.

Despite the fact that it’s not really a “secured'” view, it’s potentially useful and with some clever work, it may eventually be securable in a more formal sense.  The fundamental issue is that the client is getting all the data and then, only after it gets the data, it wipes it out.  If the client is getting the data, a clever user can prevent the jQuery from running at all and see what he/she wants to see.

There are other drawbacks.  This “security” approach is based off a _spUserId.  We’d want to really secure based on the full SharePoint security model, or at least by user name.  That becomes progressively harder, but I see some good stuff written on this subject, so I’m hopeful there’s a good answer to that problem.

The list of views themselves should be trimmed, if possible.  I haven’t tried to figure that out.  I assume it’s possible, but doesn’t really solve the fundamental security issue because someone could still just type the URL of the view they want (if they knew it).  However, trimming makes sense.  It’s a good usability feature and it helps to obfuscate things.  If an end user doesn’t know that the view event exists, they probably won’t try to use it.  Sometimes, that’s good enough.

With luck, I’ll have more to write on this subject over time.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

This is another post in my on-going series on how to use jQuery with SharePoint.
If you want to learn more about jQuery, I highly recommend: jQuery in Action by Bear Bibeault and Yehuda Katz.

Previously, I wrote about how to use jQuery to locate and hide a text field on a form.  I didn’t care for the specific approach (I was chaining parents – that’s simply isn’t done these days, at least in families of quality). 

When I first started to think about it, I knew I needed to find a <TR> to which I could invoke the hide() method.  My early effort to find the correct <TR> was something like this:

$('tr:has(input[title=Hide Me!])');

The problem with that is that it would find every <TR> tag that had any parent relationship to the Hide Me! field, even if Hide Me! is nested many levels deep in <TR>’s.  It turns out that on my sandbox form, that expression finds 9 different TR’s who have Hide Me! as a child somewhere in its DOM tree.  I realized that I could walk back up the tree from the input field itself, so that’s how I ended up abusing parents, but it didn’t sit well with me.

I gave some thought to this and one of the things I read finally made sense: I could use the not() method to trim out <TR>’s I don’t want in my wrapped set.  That led me to this:

$('tr:has(input[title=Hide Me!])').not('tr:has(tr)').hide();

The first bit finds all the <TR> tags that have the Hide Me! field anywhere in their own hierarchy.  It then strips out any <TR> that also have a child <TR>.  This leaves us with a single <TR> that:

1) Has no <TR> child records

2) Does have the input field as child. 

We can then apply the hide() method to the resulting set and we’re done.

I’m still a bit nervous about this, but not as nervous as chaining parents.

I don’t know if this is a best practice or not.  There may be a more appropriate way of identifying just the <TR> that we care about in a SharePoint form.  If you know, please post a comment.

</end>

This is another post in my on-going series on how to use jQuery with SharePoint.
If you want to learn more about jQuery, I highly recommend: jQuery in Action by Bear Bibeault and Yehuda Katz.

UPDATE (already!): I did think of a better way to locate the <TR> tag I want to hide and wrote about it here.  You may still find this article interesting anyway so I'm leavnig it up.

I want to hide a text field, “Hide Me!” as shown:

‘

The following jQuery does the trick for me:

<script type="text/javascript">

  $(function() {
 

    $('input[title=Hide Me!]').parent().parent().parent().hide();

  });

</script>

The code is saying, “find me all input fields whose title = Hide Me!.  Then, get its parent and then next parent and the *next* parent (phew!) and invoke the hide() method on that thing, whatever it happens to be.

I figured out that parent structure by viewing the HTML for the form that SharePoint created as shown:

<TR>
    <TD nowrap="true" valign="top" width="190px" class="ms-formlabel">
        <H3 class="ms-standardheader">
            <nobr>Hide Me!</nobr>
        </H3>
    </TD>

    <TD valign="top" class="ms-formbody" width="400px">
        <!-- FieldName="Hide Me!"
                 FieldInternalName="Hide_x0020_Me_x0021_"
                 FieldType="SPFieldText"
        -->
        <span dir="none">
            <input 
                name="ctl00$m$g_bdb23c2c_fde7_495f_8676_69714a308d8e$ctl00$ctl04$ctl02$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" 
                type="text" 
                maxlength="255" 
                id="ctl00_m_g_bdb23c2c_fde7_495f_8676_69714a308d8e_ctl00_ctl04_ctl02_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" 
                title="Hide Me!" 
                class="ms-long" />
                <br>
        </span>
            
            
    </TD>
</TR>

This picture shows the same, but marked up with the parents:

The first parent (1) is a span tag.  Span’s parent (2) is a TD tag and then finally we get to the real parent I want to hide (3) which is the TR tag itself.

This is a pretty terrible approach I think because it’s extremely dependent on the very specific structure of this form.  When SharePoint 2010 comes out, this whole structure could change and break this approach.  What I really want to do is craft a jQuery selector that is along the lines of “find me all the TR’s (and only TR tags) that have somewhere in their child elements an input field whose title = Hide Me!”.  I starting from the bottom and moving up.  Assuming I figure this out, I’ll post an updated “quick and easy’ post.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

This is another post in my on-going series on how to use jQuery with SharePoint.
If you want to learn more about jQuery, I highly recommend: jQuery in Action by Bear Bibeault and Yehuda Katz.

Getting started with jQuery in SharePoint is surprisingly easy (to me).  (I do have serious questions about a “best practices” approach to deploying these things to production, but that’s for another day).  I’ve just started playing with this technology and to that end, I created a sandbox environment to use.  If you’re looking to get started with jQuery, you may find this approach useful.

1. Create a Blank Site

Create a blank site somewhere in your site and call it something clever like “jQuery Sandbox”.

2. Download jQuery

You can download the jQuery javascript library from here: http://docs.jquery.com/Downloading_jQuery

Save that to to your desktop.

I have been using the “minified” version.

3. Create a SharePoint Document Library

In your sandbox site, create a document library. 

4. Upload the jQuery Library to SharePoint

Access the doc library you just created and upload the jQuery library.

5. Create a Custom SharePoint List

I’ve started with a custom list because I want to muck about with standard SharePoint forms.  You could also create a page in a pages library or web part pages and probably a lot of other places. 

Add some columns to the custom list so that you have something to run jQuery against.  My initial objectives were to:

1. Hide a field.
2. Assign a value to a field.

With that objective in mind, I added two text fields.  Over time, I’ll be playing with links, images, lookups, etc. 

6. Modify the NewForm.aspx Web Part Page and Add a Content Editor Web Part

This is a little black magic-ish , in that it’s a new concept to me.  I first learned about this from Paul Grenier, SharePoint jQuery Superstar, at his CodePlex project site: http://spff.codeplex.com/. 

Follow these steps to add a CEWP to the same page that shows NewForm.aspx for any custom list:

1. Access the custom list and click New.
2. Append the following to the URL: PageView=Shared&ToolPaneView=2

That will transform your boring vanilla data entry form from something like this:

To this:

Add the content editor web part to the page.

7. Write Your First jQuery Code

Open up that CEWP in the code view and add the following:

Here’s the actual code if you want to copy/paste:

<script 
    type="text/javascript" 
    src="../../jQuery%20Library/jquery-1.3.2.min.js">
</script>

<script type="text/javascript">
  $(function() {
 
    $('#resultsID').html('There are ' + $('a').size() + ' a tags tags on this page.');

  });
</script>

Result:
<div id='resultsID'></div>
/result

Note that the first <script> tag is referencing the actual jQuery library.  Presumably, these things change over time, so you’ll want to make sure you a) use the right name and b) point it to the correct SharePoint document library.

Bask in the Glory

If you did it correctly, you’ll see a result similar to the following:

Wrapping Up

This isn’t the only way to get started, but it’s quick, easy and isolated from your existing SharePoint environment. 

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin