Sue Hernandez's SharePoint Blog

SharePoint and Related Stuff

Category Archives: Administration

Workaround: SharePoint Workflow and Task Assignment by Email Address

SharePoint Desinger Workflow with InfoPath not filling in the Assigned To field on a Task when you specify it by Email Address
What we have here seemed to be pretty simple:  we have an InfoPath form where you filled in your name and email address, and then your manager’s name and email address (I know we could have done that automatically but that’s besides the point for this post).  Then we have a SharePoint Designer workflow that first forcibly sends an email to the Manager’s Email using the “Send an Email” action, and it then uses “Assign a To-Do Item” i.e. creates a task to the manager, AGAIN BY THEIR EMAIL ADDRESS, not by a login name.

Well to complicate the matter just a little bit, we have 2 domains – one of which is a “One Way Trust”.  Now that being said, you can add users from this second domain no problem either using the Add User people picker, or by going into a new task manually and using the people picker.  So it is getting to the other domain fine (we have already run the stsadm command -o setproperty -pn peoplepicker-searchadforests).

What the problem was, though, is that when we fill out an InfoPath form, and for the manager’s name, use an email that resolves to an account on our “local” domain, it works just fine.  However, as soon as you try to assign a to-do item, by email address, to a user in the One Way Trust domain, we end up with a blank Assigned To field in the task that was created for us.
We still don’t have a solution, but here’s the workaround:

We found a workaround.  Here’s the steps that I took to get this “working” per se:

  • Inside SharePoint
    • Create a Person Field
      • Create a new Column in the InfoPath Form Library. 
      • Make sure it is a Person or Group field. 
      • Make sure it selects from “All People”.  
      • For sake of our example, we’ll call it “Manager Assigned”
  • Inside your SharePoint Designer Workflow
    • Assign the email address into the Person Field
      • Add the action “Set Field in Current Item”
      • Click “field” and set it to the Column you created in step 1 (“Manager Assigned”)
      • Click the “value” and in the “Select Users” dialog box double-click “Workflow Lookup”
      • From the “Current Item” as a Source, choose the field in your InfoPath Form that represents your email address you want to use (“Manager Email”)
    • Pause the workflow
      • Add the action “Pause for Duration”
      • Set it to 0 days, 0 hours, and 1 minutes
    • Assign your Task to the Person Field
      • Add the action “Assign a To-Do Item” (or “Collect Data from a User”)
      • Set up your task’s name and description (and any custom fields for a Collect Data action)
      • For the person that you want to assign it to, double-click “Workflow Lookup”
      • From the “Current Item” as a Source, choose the custom field in your Form Library that represents the Person Field (“Manager Assigned”)

We also tried just pausing first and then setting the Task directly to the email address, but that didn’t work either.  Something about it not being able to resolve the user name in a timely manner when it’s creating the task.

So if you all have run in to this, and have an answer, please comment here.  If we come up with a true solution, I will update my post.


MOSS 2007 Site Collection – What happened to everyone’s permissions?

I have just run in to a case where the Farm Administrator account and 2 site collection administrators were missing 1/2 of the links on the Site Actions menu – namely they couldn’t create, edit, or view Site Settings –> All Site Settings.  When you navigated to the Site Settings page manually, you couldn’t click on some of the links such as Navigation – you would get an Access Denied error.  And finally, you couldn’t modify Lists and Libraries, and you couldn’t add people to groups or remove them from groups.

After a bunch of searching on the internet to no avail, I came across one article that seemed to be for something else, that mentioned something about a site collection being “Read Only”.  So I searched for that and I found something that I tried, and lo and behold it worked!

What it was, is that an stsadm backup had failed the night before, by all accounts reading the Application event logs.  When the stsadm backup runs, it puts the site collection in “Read Only” mode.  If the backup catastrophically fails, it doesn’t get the chance to turn the site back to read-write.

So how did we fix it?  It was in Central Administration, under the Application Management tab, in the section called SharePoint Site Management.  It is the link “Site Collection quotas and locks”.  Click that link and change your site collection to the one in question.  Under the section “Site Lock Information” you have choices of “Not Locked”, “Adding Content Prevented”, “Read Only” and “No Access”.  Change it from “Read nly” to “Not Locked” and press OK.