We can take advantage of the fact that SharePoint always knows who you are ... |
1. So, in SharePoint Designer, open the NewForm.aspx file associated with the list you're attaching the Workflow to.
2. Go to line 66 and replace this code:
<asp:Content ContentPlaceHolderId="PlaceHolderTitleAreaClass" runat="server">
<script id="onetidPageTitleAreaFrameScript">
document.getElementById("onetidPageTitleAreaFrame").className="ms-areaseparator";
</script>
</asp:Content>
with this:
<asp:Content ContentPlaceHolderId="PlaceHolderTitleAreaClass" runat="server">
<script id="onetidPageTitleAreaFrameScript">
var userText = document.getElementById('ctl00_m_g_ca8da27f_3ce7_4d29_9adf_e1a96ec0ff6b_ctl00_ctl04_ctl05_ctl00_ctl00_ctl04_ctl00_ctl00_TextField');
userText.value = document.getElementById("zz6_Menu").innerText.substring(8);
userText.parentNode.parentNode.parentNode.style.display = "none";
//document.getElementById("onetidPageTitleAreaFrame").className="ms-areaseparator";
</script></asp:Content>
The reference to zz6_Menu is for identifying where on the page the logged-in user's name is appearing (the "Welcome" drop-down menu). But you should double-check this by going View Source on the NewForm.aspx, as I've found the identifier varies depending on your SharePoint set-up.
The getElementById method is identifying the List field where you want to paste the User's Name. You'll have to View Source in order to find out what the ID Number is for the field in your list.
The final line of the new script hides the Username field (used for storing the name) on the Input form. You don't want your end users filling in their name manually.
I found that the original line of script was preventing the new script from working, so I moved it to the end of the sequence and the whole thing started working. So, just to be safe, I commented out the original line of script.
Once this is done, you can add a call in your Workflow Email to pick up the User's name from the Username field you've already added to your Custom List.
For added thoroughness, you should add an amended version of this code to the EditForm.aspx page, so that if the user comes back to the list later to edit their data, they are unable to edit the text of their name. Just open the EditForm.aspx page and alter the code at line 67 to:
<asp:Content ContentPlaceHolderId="PlaceHolderTitleAreaClass" runat="server">
<script id="onetidPageTitleAreaFrameScript">
var userText = document.getElementById('ctl00_m_g_8f8fe63d_e6dc_4f9e_b021_8c653a7bf520_ctl00_ctl04_ctl01_ctl00_ctl00_ctl04_ctl00_ctl00_TextField');
userText.parentNode.parentNode.parentNode.style.display = "none";
//document.getElementById("onetidPageTitleAreaFrame").className="ms-areaseparator";
</script></asp:Content>
Note the different value for GetElementById, as this is a different field in a different form.
Hope this helps someone.
Alan thanks for the information. I modified the code for the Newform.aspx for this particular list, saved the changes then went into the workflow and under Actions selected Email and I added the Lookup value of "Created By", however when I test the email notification I'm still receiving the Domain name\UserID format (instead of the actual name). Is there a way I can send you a screenshot of the way I have it setup? Thanks again very much for your help!
ReplyDeleteHi, Kevin ... yes, you would get the value in the Domain\UserID format from the CreatedBy field, as this method doesn't affect that field. First you need to create a new plaintext column in your list (I called mine "UserName") to hold the text of the name. Then open a NewForm and view Source so you can grab the ID value for that UserName field. Now use the ID value of the UserName field as your destination for the name text in that bit of JavaScript I've shown in the post above. Put the ID right after the section document.getElementByID as shown.
DeleteOne issue I just noticed in the NewForm.aspx code is that the "<script id='onetidPageTitleAreaFrameScript">" is indicating that the script tage must have an type attribute...
ReplyDeleteBut Microsoft didn't put any attributes in the script tag in the NewForm.aspx. If it's not throwing any errors, then I'd leave it. (It doesn't throw any errors for my users in our corporate environment with IE browsers.) But if it's giving you errors, you might have to debug ...
Delete