Patrick Lamber | LFMF

Patrick Lamber

SharePoint consultant, speaker, blogger, and geek.

In this blog post I am going to show you how you can assign the currently logged in user to a user and group form field control by using the ECMA Client Object Model and the latest version of the List Form Manipulation Framework (LFMF) that you can download for free on Codeplex. This code sample can also be used to understand how to retrieve the currently logged in user by using ECMA Client Object Model. First of all, upload and activate LFMF on your site collection and create a simple task list. We will populate the Task list with the currently logged in user. Go and modify the LFMF config.js in your site collection located under “/Style Library/LFMCoreModules/LFMConfig.js” and replace its contents with following code: var context = null; var web = null; var currentUser = null; function fillOutUserData() { context = new SP.ClientContext.get_current(); web = context.get_web(); currentUser = web.get_currentUser(); currentUser.retrieve(); context.load(web); context.executeQueryAsync(Function.createDelegate(this, this.onfillOutUserDataSuccess), Function.createDelegate(this, this.onfillOutUserDataFailure)); } function onfillOutUserDataFailure(sender, args) { alert('Not able to retrieve the current user: ' + args.get_message() + '\n' + args.get_stackTrace()); } function onfillOutUserDataSuccess(sender, args) { var user = web.get_currentUser(); var email = user.get_email(); var author = new qppfSPFormField("Assigned To", "SPFieldUser"); if (email != undefined && email != "") { author.setValue(email); } else { author.setValue(user.get_loginName()); } } $(document).ready(function () { // put your configuration here // this code is executed on every page load if (window.location.href.indexOf("/Lists/Tasks/NewForm.aspx") > -1) { ExecuteOrDelayUntilScriptLoaded(fillOutUserData, "sp.js"); } }); Consider to clear always your browser cache to avoid having old versions of your JavaScript code when loading the page. As you can see from the code above the relevant part of LFMF is just line 22, 24, and 27. The rest of the example is ECMA Script code to retrieve the current logged in user. Let us analyze the code snippets step by step: $(document).ready(function () { // put your configuration here // this code is executed on every page load if (window.location.href.indexOf("/Lists/Tasks/NewForm.aspx") > -1) { ExecuteOrDelayUntilScriptLoaded(fillOutUserData, "sp.js"); } }); As you probably already know, the LFM Framework works with jQuery. Hence, we have to guarantee that our JavaScript code is launched when the document is ready. Since the LFMConfig.js is called on every page load, we have to distinguish our code parts by using the if statement on line 4. function fillOutUserData() { context = new SP.ClientContext.get_current(); web = context.get_web(); currentUser = web.get_currentUser(); currentUser.retrieve(); context.load(web); context.executeQueryAsync(Function.createDelegate(this, this.onfillOutUserDataSuccess), Function.createDelegate(this, this.onfillOutUserDataFailure)); } This code snippet calls the ClientContext of the Client Object Model and prepares a request to retrieve the current user data. This information is retrieved from the current user property from the current web object. The “executeQueryAsync” method starts an asynchronous call that might either succeed or fail. We are going now to see what happens if the request succeeds. function onfillOutUserDataSuccess(sender, args) { var user = web.get_currentUser(); var email = user.get_email(); var author = new qppfSPFormField("Assigned To", "SPFieldUser"); if (email != undefined && email != "") { author.setValue(email); } else { author.setValue(user.get_loginName()); } } If the request succeeds, the code listed above will be executed accordingly. Line 2 retrieves the current user data while line 3 we are retrieving the user’s e-mail address (works well in Office 365). Then LFMF comes in action and binds the “Assigned To” field of the form. Last but not least, if the user’s e-mail was successfully retrieved, then it is going to be assigned to the “Assigned to” field. If this is not the case, then the system tries to fall back and retrieve the current login name of the user and assign it to the “Assigned to” field. The rest is history .   Hope this helps, Patrick

  Sometimes customers using SharePoint Wiki or Page Libraries require that the “Recently Modified” page section on the left hand navigation disappears. There are two potential solutions to solve this issue: Modify the master page structure – not preferred Attach a CSS file and use the “.s4-recentchanges” class to hide this section as described here here (http://marijnsomers.blogspot.com/2011/04/hide-recently-modified-items-in.html) – preferred On the other hand, in some environments the customers do not have any permission to modify master pages or attach CSS files due to governance reasons. In such a case, a customer approaches another solution by adding a Content Editor Web Part and “injects” the CSS code described above. This solution has two drawbacks: This is only a local change. Newly added libraries must be modified again The Ribbon bar is not visible by default when opening the page. This article shows how with some easy steps it is possible to solve this issue with the sandboxed solution List Form Manipulation Framework (LFMF). The solution presented here can be activated by site collection owners and holds for all libraries located in the site collection. The steps that you have to follow are: STEP 1: Download the latest LFM Framework version (http://listformmanipulation.codeplex.com/) STEP 2: Upload and activate the LFM Framework solution on the target site collection (http://www.lamber.info/post/2011/08/20/LFMF-installing-and-activating-the-sandboxed-solution.aspx) STEP 3: Deactivate the jQuery Feature provides by LFM Framework (optional) – described below STEP 4: Update the LFMConfig.js used by the LFM Framework – described below STEP 3: Deactivate the jQuery Feature provided by LFM Framework This is an optional step that you should do if you already have jQuery running on your pages. LFM Framework loads automatically a jQuery plugin on every page load. This is not required if you already have such a jQuery plugin activated. Please note that this operation can only be executed by a site collection administrator: Site Actions -> Site Settings Site Collection Features Deactivate the Feature “LFMF Core – jQuery Module STEP 4: Update the LFMConfig.js used by the LFM Framework The “LFMConfig.js” file is loaded on every page load. Hence, we can use jQuery syntax to manipulate and hide the desired DOM elements. The configuration file can be found in the site collection root under “Style Library/LFMCoreModules”. Replace the contents of this file with the next code snippet: jQuery(document).ready(function () { var recentlyModified = jQuery('.s4-recentchanges'); if (recentlyModified.length > 0) { recentlyModified.hide(); } }); you can modify the file by downloading it and making your changes. Afterwards you have to upload it again. Alternatively, use SharePoint Designer to make the changes to the file directly. Summary This article showed how the “Recently Modified” section of Wiki or Page Libraries can be hidden by using the LFM Framework. This might be a feasible option if you want to have a global setting related to the site collection and do not have any chance to modify the master page or attach CSS files.

I had busy times the last months due to conferences and a lot of customer projects. Unfortunately, there was not much time left for writing blog posts. Nonetheless, I am back again for blogging and start today with a solution to a problem I faced in one of my customer projects. In this project it was necessary to access managed metadata columns in a NewForm.asxp and an Editform.aspx and populate them with values. I did it by using jQuery (for simplicity) to access the desired field. It was important for me avoiding doing any changes to the forms themselves. Fortunately, I was able to use my Codeplex project LFM framework to address the desired form and fields accordingly (need to do some advertisement ). At this stage of Codeplex project there is no direct managed metadata field integration. I am going to change this soon. In that way, everything can be directly addressed by the LFM framework. Just wait a little bit for the next release. First of all, we have to identify the correct field on the form. To do this we are going to use as “unique identifier” the display name of the field. Unfortunately, I did not find a better solution to this problem due to different rendering behaviors from browsers (the world is not governed by IE only). Therefore, there does not seem to be a reliable way to address the fields with the internal names of the columns. Now let us see how we are going to reference the managed metadata field by using the display name shown in the form: var displayName = "Put the Display Name here"; var inputControl = $('div[class="ms-taxonomy-fieldeditor"][title^="' + displayName + '"]'); if (inputControl.length == 0) { inputControl = $('div[class="ms-taxonomy-fieldeditor ms-taxonomy-writing"][title^="' + displayName + '"]'); } The first line hast to be changed with the desired display name of your form you want to address (e.g., Places, People, Organizations). Since the managed metadata field that we are going to reference has two possible states, we have to live with two jQuery queries: the first query is valid for managed metadata fields without mouse focus “ms-taxonomy-fieldeditor” the second query is necessary when the managed metadata field has a mouse focus. The class of this DOM element changes to “ms-taxonomy-fieldeditor ms-taxonomy-writing” Now, that we have a referenced managed metadata field, we are going to populate it with some values. If you want to populate the field with multiple values, then separate them with a semicolon var value = "put your value here. Multi valued fields separated by ;" var editableRegion = inputControl.find('div[id$="editableRegion"]'); if (editableRegion.length > 0) { editableRegion.html(value); var taxonomyParent = editableRegion.parent().parent().parent(); if (taxonomyParent.length > 0) { var taxonomyObject = new Microsoft.SharePoint.Taxonomy.ControlObject(taxonomyParent.get(0)); taxonomyObject.validateAll(); } } From the code snippet above it is possible to see that we write the values into the editable region of the managed metadata column. Unfortunately, this is not enough to populate managed metadata columns with the common ID-Value pairs that this column is expecting. Therefore, we have to use the Taxonomy.ControlObject Javascript class from Microsoft to validate the field values. (Credits to this blog post of Thomas Zepeda McMillan for giving the necessary hints). This fancy class takes the values that we just populated in the editableRegion element and validates them by using some taxonomy web services in the background. This validation corrects the necessary ID-Value combinations needed by the column. I am going to integrate this code in the LFM framework soon. So stay tuned. Hope this helps, Patrick

Hi, recently while passing through the Microsoft forum threads I found an interesting request coming from a forum member. He wanted to change the default values of a form field depending on the current content type selected. This works as long you use different fields with different default values in your content types. It becomes however a problem if you share common columns and want to have different default values. Therefore, I was looking for a solution to this problem and found out that the LFM framework could be used to achieve this task quite simply. You can find more information about this tool on the official codeplex page. A small demo Imagine we have a custom list “CustomList” with two content types associated: “Item” and “Task” have the column “Title” in common. You could define a default value for the “Title” column, but this default value is the same for both, “Item” and “Task”. In our scenario, however, we would like to have completely different default values for this column. Imagine we would like to have the “Title” column of an “Item” set to “This is a new item”. On the other hand, we would like to add the default value to the “Title” column of a “Task” to “This is another task”. To accomplish this we need to differentiate the content types when a form is opened. The form could be opened in these ways when working with a list. (Before you start complaining about my bad picture I can only say that: I am a computer scientist and not a designer ). When a user clicks on 1, 2 and 4, the NewForm.aspx with the default content type (in our case the “Item”) is opened. Button 3 opens the NewForm.aspx with the “Task” content type associated. I noticed that you can find out through JavaScript what is the current associated content type by following these rules: When a user clicks on 1 and 4, the NewForm.aspx is opened and no additional information is shown When a user clicks on 2 and 3, the NewForm.aspx is opened and an additional parameter “ctype” is passed in the url as get parameter And exactly the “ctype” assigned saves us from banging our head against the wall. With this information we can add some code to our LFM framework to assign different default values when different content types were selected for creating a new item. Please find the code snippet below. Add this code to the “LFMConfig.js” of the LFM framework: $(document).ready(function () { // the ctype id of the content types associated to the "CustomList". Change these ids accordingly // you can find them in the URL when clicking on the Content Type under List Settings var ItemContentId = "0x01008068822D1BEA4D4CA1EAE00773348A03"; var taskContentId = "0x010800B9DDBA5F57BAEE4A8BF98D065412E690"; // verify if this is the customNewForm. Change the URL accordingly. var isCustomNewForm = window.location.href.indexOf("/Lists/CustomList/NewForm.aspx") > -1; // add the non default content types first if (isCustomNewForm && window.location.href.indexOf(taskContentId) > 1) { var title = new qppfSPFormField("Title", "SPFieldText"); title.setValue("This is another task"); // add your default values here for the Task // if all non default content types were not found, then it should be the default content type } else if (isCustomNewForm) { // add your default values here for the Item var title = new qppfSPFormField("Title", "SPFieldText"); title.setValue("This is a new item"); } }); The code snippet is pretty straightforward. We use the LFM framework to differentiate which content type is currently selected in our “NewForm.aspx” by verifying following: if it is the CustomNewForm and the URL contains the id of the Task content type associated then it must be the “Task” all other combinations are related to the “Item” content type (which is our default content type) if you want more content types, then add the if statements always before the default content type branch you can get the associated list content type id in the URL when clicking on the content type under the list settings The rest is only a standard usage of the LFM framework. The final result looks as follows (first picture when clicking on the default content type. Second picture when clicking on the Task content type). Summary In this small example I showed how the LFM framework can be used to manipulate default values in a NewForm.aspx depending on the current content types selected. You can find more information about this tool on the official codeplex page.   Stay tunes, Patrick

I updated today the List Form Manipulation Framework (LFMF) project to the version 0.5 on Codeplex. In this version you are getting more support for some of the missing fields such as: Enhanced Rich text Field Multi-Lookup Choice Field In this post we are going to see the syntax for setting field values with this framework. The final result of a testing form can be seen in the next picture: Go to the project documentation page on Codeplex to see more usage examples of this framework The picture before is a custom list. The columns created for this demo are described below: Name Type Notes Title Single line of text   MuliLineRich Multiple lines of text Enhanced rich text is enabled MultiLookup Lookup Allow multiple values is enabled pointing to a test list with values ranging from LookupValue1 to LookupValue31 ChoiceFieldDropdown Choice Drop-Down Menu selected ChoiceFieldRadio Choice Radio Buttons selected ChoiceFieldCheck Choice Checkboxes selected The code to fill-out these fields is shown directly in the next code snippet. // reference the title column and add a value var title = new qppfSPFormField('Title', 'SPFieldText'); title.setValue("Newly added controls"); // reference the rich text column and add the value // note that you can also use html formatting var multiline = new qppfSPFormField('MultiLineRich', 'SPFieldNote'); multiline.setValue("Here richtext content"); // reference the dropdown and select the value var choiceDropDown = new qppfSPFormField('ChoiceFieldDropdown', 'SPFieldChoice'); choiceDropDown.setValue("Enter Choice #2"); // reference the radio buttons and select the value var choiceRadio = new qppfSPFormField('ChoiceFieldRadio', 'SPFieldChoice'); choiceRadio.setValue("Enter Choice #2"); // reference the checkboxes and set multiple values // values can be separated with the ";" sign var choiceCheck = new qppfSPFormField('ChoiceFieldCheck', 'SPFieldChoice'); choiceCheck.setValue("Enter Choice #2;Enter Choice #3"); // reference the multi-lookup field and set mutliple values // values can be separated with the ";" sign var multiLookup = new qppfSPFormField('MultiLookup', 'SPFieldLookupMulti'); multiLookup.setValue("LookupValue2;LookupValue3"); Like in the examples we saw last time  we have the ability to hide complete rows with the “hideRow()” command and to read and set values directly from GET parameters. In the next version we are expecting the implementation of “External Data” columns. So stay tuned.   Patrick

Recent Comments

Comment RSS

Page Visitors

 

Control panel