Thursday, April 10, 2008

Comparing InfoPath Fields - Case Insensitively

Currently have a form deployed which has 4 different views:
  1. User
  2. Manager
  3. Process Owner
  4. DBA
Each of the first three users (User, Manager, Process Owner) have an authorization field with an automatically filled in date field. Each user can only read/write for their authorization, and have read access to the authorizations below them (User cannot see anyone else's, Manager can see User's, Process Owner can see Manager's and User's, DBA can see all).

A problem arose where the Process Owner was actually the user's manager as well, but my rules for determining which view is presented to the user only showed this person the Process Owner view. I did not want to create a new view just for the case of Process Owner == Manager, so I did the following:
  1. Set the Manager's authorization field to Read/Write on the Process Owner view
  2. Added a conditional formatting element to the Manager's authorization field to set it to read only when the managerID field does not equal the InfoPath function "userName()"
This was great, except everything is case sensitive, and there is no standard "toUpper" or "toLower" functions to standardize multiple fields on one case...enter translate.

The resulting expression used in my conditional formatting is (broken onto multiple lines for ease of reading):
translate(
substring-after(
/my:myFields/my:grpEmployeeInformation/my:managerID,
"\"),
"ABCDEFGHIJKLMNOPQRSTUVWXYZ",
"abcdefghijklmnopqrstuvwxyz") !=
translate(
xdUser:get-UserName(),
"ABCDEFGHIJKLMNOPQRSTUVWXYZ",
"abcdefghijklmnopqrstuvwxyz")

Rather long and cumbersome, but you can see both the left and right hand sides of the "!=" translate all capital letters to their lower case equivalents. The substring-after() bit was just an artifact of the structure of my form, where the managerID field is in the format of "domain\username".

Note: Since this form uses the "userName()" function, it will probably require full trust.

Enjoy!
--andrew

Wednesday, April 2, 2008

DataView Web Parts and Page Layouts

The DataView Web Part is a nice tool to customize the way information is presented on a page. Unfortunately, this web part is not available through the browser's "Add Web Part" interface, and must be added through SharePoint Designer. The problem I ran into was that pages attached to a page layout cannot be directly modified within SharePoint Designer.

I decided to detach the page from its layout and add the DataView Web Part. Everything seemed to work, except I started to receive errors stating "This Web Part Page has been modified since you opened it." I figured this was related to detaching from the Page Layout (I may have hosed something up unknowingly). I then reattached the page to its layout and everything ended up working fine.

Therefore, if you need to add a DataView Web Part to a page attached to a layout, I suggest doing the following(all done within SharePoint Designer):
  1. Detach the Page from the Page Layout
  2. Go through the necessary steps to add a DataView Web Part to an existing zone on the page
  3. Reattach the Page to it's Page Layout
This was fantastic since detaching/reattaching to layouts does not change any web parts or customizations made to those web parts. Also, once the DataView Web Part is on a page, you can simply modify it's display through the browser using the XSL editor.

Note: I have not attempted to reattach a page to a layout after new zones have been added and do not know exactly what will happen.

Enjoy!
--andrew