the at&t hidden interface for call forwarding

• Immediate Call Forwarding: Dial *21* plus the 10-digit number to which your calls should be forwarded and #. Press Send.
• Busy Call Forwarding: Dial *67* plus the 10-digit number to which your calls should be forwarded and #. Press Send.
• Call Forwarding No Reply: Dial *61* plus the 10-digit number to which your calls should be forwarded and #. Press Send.
• Call Forwarding Not Reachable: Dial *62* plus the 10-digit number to which your calls should be forwarded and #. Press Send.

unlike this http://www.wireless.att.com/learn/basics/choosing-features-services/call-forwarding.jsp reference sheet, the above are direct ways of manipulating the call forwarding features that many of us enjoy (without knowing).

dirtybird's bbq in golden gate park san francisco

the PeopleEditor and how Validation sucks in SharePoint

Just over another hurdle in the SharePoint steeplechase. This one involves the glorious PeopleEditor control and how to make sure the user has some client-side feedback before they post their selection. Through the nest of blogs and comments about the general ASP.NET versus the universe of SharePoint problem, the best solution seems to revolve around hacking the client side javascript and doing the most manual processes imaginable to get consistent validation.

Precisely, I mean that within the PeopleEditor should support simple validation out of the gate, but the AllowEmpty property doesn't work (see Karine Bosch’s comments from this blog link). Then you end up going through the following failure steps before the aforementioned hack emerges as the winner:

1. AllowEmpty property of PeopleEditor (Karine Bosch’s link) #FAIL
2. ValidatorEnabled property of PeopleEditor (Karine Bosch’s link) #FAIL
3. Adding the ASP.NET RequiredFieldValidator element within the ASP form (shereen's blog link) #FAIL
4. Calling Page.Validate() / Page.isValid within onsubmit() (Ben Cline's blog link) #FAIL (because it is really challenging to server-side redirect /repost the user data back to the second step of an association form within a workflow association)
5. Inserting a RequiredFieldValidator by override CreateChildControls() within the code-behind-form (see link to a blog SharePoint Solutions team, the "experts and pioneers on Microsoft SharePoint") sorry, another #FAIL, though from 2006
6. (Now we are getting closer.. ) A similar problem with a close kin of this SPControl is solved by Greg Galipeau in his post about SharePoint DateTimeControl Validation. But since it is a long day and I'm not getting any younger with all this chasing blog trails, #FAIL

Now the winning hack, by the same person Shereen (from #3 above) who got it right the second time - thanks for being an extremely passionate ninja and posting your updated solution (which I'm going to copy below incase it disappears one day into the digital ether)

This post is an update to a previous post I had written on validating the PeopleEditor control on post back. In that particular post, I described the challenges of getting a PeopleEditor control, within a custom application page, to validate correctly as a required field on the client side (I had server side validation already in place and
working correctly).

For the most part, the solution I outlined worked well,
except for some situations where other controls on the page were performing
their own post back (for example, a data grid in edit mode). I found that on
submit of the entire form, the ASP.NET required field validator for the
PeopleEditor control would kick in informing me that the field was required.
However, there was a valid entry in the control so I could only conclude that
the post back by some other control on the page was mucking up the view state
for the PeopleEditor control and on submit the form was no longer aware that
this field did in fact have a value in it.
The MSDN article found here outlines my problem exactly with the eventual solution further down in the thread. I just wanted to highlight it here because it was exactly what I needed to resolve my issue. Thank you to Jan Lange for posting his solution!
inside the script tag, in the asp.net page's header (I've got to move to a blog that I can post code in. ridiculous blog=#FAIL)

language="javascript"
function CheckProjectManager(source, arguments) {
if (aspnetForm.ctl00_PlaceHolderMain_ProjectManager_downlevelTextBox.value == "")
arguments.IsValid = false;
else
arguments.IsValid = true;
}

<SharePoint:PeopleEditor
ID="ProjectManager"
AllowEmpty="false"
ValidatorEnabled="true"
MultiSelect="false"
runat="server"
SelectionSet="User"
Width="200px"
TabIndex="2" />

<asp:CustomValidator
ID="rfvProjectManager"
runat="server"
ControlToValidate=""
ErrorMessage="Required"
Enabled="true"
ClientValidationFunction="CheckProjectManager" />

Just to outline, what Jan eventually did was create a custom validator that called a javascript function to validate the control. Within that function he checks to see if the control is empty and stores the results of the validation in the IsValid property of the ServerValidateEventArgs object. Notice that he also sets the ControlToValidate property to “”.

http://blog.qumsieh.ca/2009/02/12/validating-a-peopleeditor-control-on-postback/

The e-mail message cannot be sent. Make sure the outgoing e-mail setting for the server are configured correctly

It seems like there are hundreds or thousands of people out there that have come across this little SharePoint sendemail bug. Beware this error message is a red herring! My suspicion is that through a series of unfortunate events around the sequencing / pipelining of workflow activities, the sendmail activity gets terminated prior to having a chance to become a fully dehydrated object. Postulations aside, here is the fix I used:

Observation 1 from 12's hive logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS):
w3wp.exe (..) 0x.. Windows SharePoint Services, General, 8kh7, High, Cannot complete this action. Please try again.

Observation 2 from Workflow History:
Error, System Account, The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly.

So I fixed my <sendmailobject>_MethodInvoking by binding the sendmail activity's email fields (to:, cc:, body:, etc) to class variables and then assiging those variables within the method_invoking for the sendmail activity.

Before:
createPMApprovalEmail_MethodInvoking() {
createPMApprovalEmail.To = this.workflowProperties.OriginatorEmail;
..

After:
createPMApprovalEmail_MethodInvoking() {
this.createPMApprovalEmail_To1 = this.workflowProperties.OriginatorEmail;
..

Chris Buchanan wrote about this solution first, whose blog I stumbled upon by finding similar frustrations at Jason's blog.

Workflow History versus Audit Trail

MOSS removes the association between workflow tasks, history items and the workflow 60 days after the workflow has been completed through the workflow cleanup timer job for performance reasons. Consider this next suggestion a workaround for that bad design; most companies that develop custom workflows will want that history around for some time. Several alternatives are available, albeit brute-force methods, but the one I elected to go with is to place the following bit of configuration in the workflow.xml prior to associating a workflow.

workflow.xml

<Elements>
 <Workflow>
  ..
  <MetaData>
    <AutoCleanupDays>9999</AutoCleanupDays>
  </MetaData>
  ..

See Brian Farnhill for more documention on this issue.