Skip navigation
All Places > Getting Started > Blog > 2017 > September
2017

parent child forms listviewcontrol beginner

 

Me

First of all, excuse my english, please.

I'm not an expert, but I would like to share with you my first significant development using Nintex Forms. It could be easy, but I'm very happy with it  

 

I have just developed a Parent / Child structure using List view control to show child list inside Parent Form. The idea is to have child data in a independent list in order to manage the elements properly.

I'm not satisfied with the repeating section to do it, because data is not easy to manage later, for example if you want to do tasks for each child element using workflow, or to make a report downloading the lists to Excel file and working with Power Pivot.

 

My targets are:

- To have the child data only in one place (not in XML in the parent list and the duplicate in a child list)

- To have the parent "primary key" in the child list to have the relationship in the reporting system (in my case Excel and Power Pivot functionality)

- To allow the update of the created child items when you want

- To use workflow to create / manage tasks using the child elements

 

The example:

In this case the parent child has data about process events in a Chemical Industry, and the child list has actions to do by the staff related with each event in the parent list.

 

The process:

Let me show my parent form. I use "tabs" to distribute and organize data using the wise advices learned in the forum 

 

The red mark shows the "primary key" of the parent element, generated using workflow when the element is created.

 

The tab "Acciones" has the list view control with the child items. You can see the primary key in the first column:

The list view control is filtered using a calculated control in the form, who stores the "primary key"

So, only the actions related with the parent item appears 

 

 

(Be careful here, you can filter and sort the list using the list headers. If you do it, filter values could be removed. I'll show you how to avoid it later on)

 

New child item

To create a mew child item, I have prepared a button on the top of the list.

 

 

 

The button is "save and send" type, and I use URL redirection property to point to the child form with the parent ID at the end of the URL string:

 

http://xxxxxxxxxxxxxxxxxxx/Lists/I_OP_Acciones/NewForm.aspx?ParentID=ID 

 

I'm not using the list "Add new item" link (by default it appears in the Sharepoint list) because I don't know how to pass the ID variable to it. In fact, I just remove the link to avoid troubles. I'll explain how to do it later on.

 

In the child form, I get the ID to update the key item. Let me show how:

 

I use a calculated control to geet the ID value from the URL string, using the following formula:

 

buscar("Incidentes_Operacion","ID",fn-GetQueryString(ParentId),"Num_Incidente")

 

Buscar (in spanish here) is Lookup the parent  list "Incidentes_Operacion" to get the parent primary key "Num_Incidente"

 

fn-GetQueryString is the function to get the variable from the URL string (Thank you very much Marian Hatala )

 

Now, you connect the calculated control with the appropiate child column and the relationship is done 

 

Updating an existing child item

In case of you want to update an exisiting child item, yo don't need to pass the key, because the child item get it when it was created. So, you can use the update action from the child list menu in the list view control in the parent form:

 

 

Back to the parent form from the child form when you finish edition:

By default, when you save the child form, Sharepoint come back to the list. So you need some code to return to the parent form (and to the related parent item). I use the following strategy:

 

The button "GUARDAR" is save and continue button. The user click on it to save data. The button Volver is not a button, is a calculated field with an hyperlink (there are  examples in the community of how to do it):

The formula that I'm using to back to the parent form is:

 

"<a href=\" http://xxxxxxxxxxxxxxxxxx/Lists/Incidentes_Operacion/EditForm.aspx?ID="+CC_Parent_ID+" \">Volver</a>"

 

CC_Parent_ID  is the calculated field I use to get the parent ID from the parent list using lookup formula and using the child column with the "primary key" as an argument. So, using this link you navigate back to the parent form.

 

This method has to advantages:

- You came back to the parent form from both new item action or updating action 

- The parent form is UPDATED with the new data when opens 

 

Finishing

 

Removing "add new item" funtonality in the chil list view and header filter / sort functionality:

 

As commented, you need to remove "add new item" and "header filter / sort" functionality from the child list into the parent form to avoid mistakes.

 

To do it, you must to edit the page when the parent form is alocated and include a web part selecting "Command sequence Editor" (I think is something like that, in spanish is "Editor de Secuencias de Comandos":

 

Then you must include the following code fragment:

 

The first fragment is to remove the add new link

The second one to remove header funtionality, in this case in the primary key column

 

Save the changes and the work is finished. 

 

Thank you for your attention. Any comment will be wellcome.

 

BR

greenawayr

Workarounds

Posted by greenawayr Champion Sep 29, 2017

So this morning I was trying to write to a date & time field on a button click on the new responsive forms designer. I clicked on the button settings > Advanced > Connected To but in my list of columns, my Date & Time column wasn't there. It appears that only the text based columns can be written to here. This was frustrating, especially as you can write the date and time to a text column using the common references.

 

Ah-ha, I wonder? Let's see.

 

That light bulb moment you just witnessed was me thinking, if I set the button to write to a Single Line of Text (SLOT) using the "Current Time" reference, I get myself a date and time, that's fine, but no good for reporting really, I want my datatype to be Date and time, not just a string containing the date and time. Nevertheless, I published the form and knowing that my button was configured how I wanted it to be, then in my list, head to the List Settings, head to the SLOT column settings for the column I've just connected my button to and in these settings I can switch the data type from SLOT to Date and Time. 

 

Now here comes the test, firstly, is my form still configured? Head back to the form designer and check my button settings, all the configs are still there...great.

 

Now create a new item in my list and hit that button and Bingo! Date and time written to a date and time column, even though the form designer didn't really want me to. Perfect.

 

I'm guessing that Nintex didn't want people to be able to write to date and time columns because they might be prone to putting something other than the date and time in here and values will be lost, but as they give us a reference, it still seems odd to me.

 

Anyway, this relatively simple fix means you can write to a datatype using certain actions that you might not have thought you could. 

 

I wonder whether the same might work with a Choice column (you could allow Fill In choices for flexibility perhaps)?

 

On that note, what other workarounds/fudges/obstruction breakers/loopholes have you discovered in your journeys through Nintex? Not after whizzy javascript solutions here, stuff that people can do from the interface with no custom code. Intrigued to find out what else lingers out there.

Nintex is becoming ubiquitous in the global IT landscape as adoption increases in their cloud offerings building on top of their highly successful on-premises solutions. Because of this, knowledge of good workflow design and development practices specific to Nintex is paramount.

Here below is a short list of key tips to help optimize performance and maintainability of your solutions. 

Tip #1 - Use Workflow Constants

One of the best features with Nintex on-premises is their ability to store credentials for a service account as a workflow constant. When a credential has been created, you can use those credentials without having to know the name and password of the account. The credentials are stored in the Nintex Workflow configuration database and are encrypted with DES encryption. Workflow constants can be created at the Site, Site Collection, or Farm level. You can see how it gets setup in the image below.

Workflow Constants diagram

To use a stored credential, simply click on the 'Select credentials' lock icon and select the credential constant from the lookup dialog box. More details can be found here.

Tip #2 - Processing and Load

Only affecting on-premises, a consideration that is often overlooked is the effect on performance of different actions within the workflow which can slow down its execution affecting performance. 'Execute SQL' or 'Query LDAP', for example, require more processing while 'Log to history list' and 'Build dynamic string' require much less. Nintex recommends breaking actions with a heavier load out to their own separate sub workflows.  

Any updates to the list, start/stop workflows, or update XML actions do not get processed immediately and are not necessarily executed in the order of the workflow. These actions will be batched up and executed according to what type of actions they are – Nintex or Microsoft. For example, this:

Workflow Execution Order pic 1

will actually execute as this:

Workflow Execution Order pic 2

 

This is happening due to the Nintex actions getting batched together and executing before the Microsoft "Update List Item" action. Another wrench in this puzzle is that although the Nintex batch may start first, it may not complete execution prior to the Microsoft action. You might think to put a 'Commit pending changes' action after the Microsoft action but that is still not a guarantee. The permissions action, for example, takes longer to complete and can possibly end after the 'Update List Item' action. It is better to use 'Pause for Duration' and set it to at least 30 seconds to make sure all the actions have completed before continuing. Alternatively, you can also use 'Wait for Field Change in Current Item' if that works for you. If you are on Office 365, Nintex for Office 365 does not have 'Commit pending changes' so you should replace it with a 'Pause for Duration' or 'Wait for Field Change in Current Item' action.

Tip #3 - Build Your Content

When designing your workflow, in O365 or on-premises, it is ideal to have a workflow that has the smallest number of actions. The benefits are in reduced server load, speed of execution, and reduced complexity. One of the recommended techniques used in developing workflows is building your content by adding relevant information to a variable as it becomes available.

For example, email body content often has to be formatted using basic HTML to display tables and other formatting. This can be built in a variable as the data is collected. Using a "Set Workflow Variable" action, you can set the variable to itself plus the additional formatting and data. So a var_EmailBody variable would have a value of "{Variable:var_EmailBody}<TR><TD>my new data</TD></TR>" when adding new data.

 The results of this method are very apparent. Workflows that previously looked like this:

Bloated workflow design

Can now start to resemble this:

Streamlined workflow design

 

Resulting in less actions, faster execution, and a better workflow overall.

Tip #4 - Avoid Getting Throttled in SharePoint Online

One of the most frustrating things that can happen when running a workflow is for it to get throttled or even completely blocked. This happens when the number of user calls is too high and it exceeds a threshold. A scenario where this might occur would be updating properties or lists in SharePoint Online in a batch to keep it in sync with another line-of-business application. The result is being redirected to the throttling page with failing requests, REST calls returning a 429 "Too many requests" error, or worse getting completely blocked with a 503 "Service unavailable" error.

While SharePoint Online can handle a high volume of calls, good workflow design practices should still be followed so this can be prevented. Keep an eye on the number of looping iterations to make sure they are not causing hundreds of updates and requests at a time. In the case where a high number of immediate updates are required, consider including pauses in your loops to alleviate the load and decrease the chance of getting throttled. 

Tip #5 - Workflow Version Control in Office 365

A great feature of Nintex on-premises is how versions are maintained when a workflow is saved or published. This allows you to access prior versions of your workflow, export it, and more. It is something that protects your workflows and their development.

Unfortunately, the current version of Nintex on Office 365 does not support this feature but it can still be emulated with the use of versioning in document libraries. First, create a document library with versioning turned on called "Nintex Workflow Backups". Then whenever you would like to back up the current version of your workflow, export the workflow and add the file to the document library. Be sure to include comments of the changes made since the prior version. This best practice helps you and others that wish to review the developmental progression of the workflow.

For those that are looking for full versioning, please review the request on Nintex User Voice:  Version Control and be sure to up-vote it!

Tip #6 - Set Error Notifications

Another feature within Nintex on-premises is setting up error notifications. Whenever a Nintex workflow errors, it will send an email notification letting you know of the error and the workflow it occurred in. Setup is in Central Administration and applies for all workflows. While this feature is not available in SharePoint Online, there is a simple workaround. Go to your workflow history list and create a workflow that runs on new items. Set the workflow to do a "contains" on the description field. Whenever the word "error" is found, send an email notification. This method also has the advantage of being workflow-specific allowing you to send notifications to different users.

There is also a user voice topic for Nintex User Voice:  Workflow Errors

Tip #7 - Use Child Workflows

When a business process is very complex or when multiple different processes use the same sub-process, child workflows can be created to reduce the complexity by separating or sharing functionality across different workflows. They reduce complexity by having multiple instantiations from separate workflows point to a focused process for execution. Child workflows are an act of process recycling that leads to easier testing and better performance.

One example of the use of child workflows would be purchasing requests. Imagine a company with several departments – Information Technology, Human Resources, and Marketing – each having their own separate requisition workflows. The requisitions first have to pass departmental approval and then get sent to Accounting where the actual requisition is processed. Rather than copy that Accounting process in each workflow, a child workflow would be created and called from each original workflow. Another advantage to this method is that when the Accounting process changes, only one workflow requires updating.  

Tip #8 - Consider Office 365 When Developing Your On-Premises Workflows

With companies moving more and more to the cloud every day, it is important to consider the ramifications of decisions made when designing an on-premises Nintex workflow. While Nintex is improving its online products every day, all actions are not currently supported by SharePoint Online or migration tools. With products like Sharegate, unsupported actions will be replaced with a placeholder action that has the name of the original unsupported action. This lets you maintain the structure of your workflow and easily replace them with supported actions.

Another consideration to remember is that the Nintex workflow history will not migrate. Custom workflow actions or user-defined actions will also not migrate so try to use the out-of-the-box actions as much as possible. And remember that the last saved version of the workflow will migrate, not the last published version, so be sure to keep good habits on your version control. 

 

Sometimes when you use an Action Set to execute and/or group some actions, it appears when part of the main flow.

 

 

 

It happens that when you have actions nested inside others, you'll have the possibility to mark them to run as the workflow owner only from the principal one.

 

Only actions at the root path of the workflow will have the Run as Workflow Owner option.  If you have an action in any branch, this option will not be available.

My last project required creation of a dynamic list of approvers for the approval process (a coincidence? ), based on a location and volume threshold. And some other parameters, but this is not a case. At first I naturally thought about a list, that would hold such mappings for me. Then I thought to query that list within a workflow, using filtering to gather only a specific subset and then, using a state machine, to go through and assign tasks.

 

But there was a catch! Customer expected, that the form should allow to display that list of dynamically gathered approvers and then to show how each one expressed approval. And with the possibility to add or remove existing ones!

 

Naturally, I decided to use the repeating section control, but I didn't know how to fill it dynamically. I managed to do that however, and the results look like this:

And the source list for data lookups:

How such dynamic repeating section can be made?

Step by step. Let's begin!

 

The data structure

  1. Locations (just a simple list with title)
  2. ApprovalThresholds - a list built of the following fields:
    1. TItle
    2. Approver (person field, many users allowed)
    3. Location (single lookup)
    4. Threshold (number)
    5. OrderNo (number, in my case it was used to identify a group to which specific user belongs)
  3. WorkingList (it was called differently, but for the demo let's stay with this name )
    1. Title
    2. Location (single lookup)
    3. Volume (number)
    4. Approvers (multiline text field, plain text)

 

The form

Then I created a form for the WorkingList list. With some enchantments of course:

  1. Volume field was given a JavaScript variable name: var_Volume;
  2. Location field was given a JavaScript variable name: var_Location;
  3. And then I deleted the default "Approvers" field, the textarea, and replaced it with a repeating section:

The repeating section has added a CSS class: approvers:

It is built of three input fields:

  1. Approver name - is given a CSS class: approversApprover
  2. Approver email - is given a CSS class: approversApproverEmail 
  3. Approval group - is given a CSS class: approversOrderNo 

 

There are also two checkboxes, one is having a JavaScript variable name: var_IsEditMode, the other var_IsNewMode, to pass information to the script how to behave, having set the "Default value" to "Expression":

 

And basically that's it for the form. All the magic is habdled by a jQuery script.

 

The script

Script is doing the following things:

  1. It binds change and blur listeners to the Volume and Location fields;
  2. It defines function that is triggered by the listeners events;
  3. It adds dynamic controls to the repeating section once it is in the edit mode.
  4. It also allows to hide or leave untouched controls for the repeating section (hideNativeRepeatingSectionControlls variable)

 

AD. 1 - listeners and bindings

var clientContext = new SP.ClientContext();
var siteurl = _spPageContextInfo.webAbsoluteUrl;
var hideNativeRepeatingSectionControlls = 0;


NWF$(document).ready(function () {

    //hide "add row" link in repeating section
    if (hideNativeRepeatingSectionControlls) NWF$(".approvers").find('.nf-repeater-addrow').css("visibility", "hidden");

    //trigger if location, CapitalExp or Volume is changed - recalculate list of Approvers
    NWF$("#" + var_Location).change(function () { retrieveApprovers(); });
    NWF$("#" + var_Volume).blur(function () { retrieveApprovers(); });

    if (NWF$("#" + var_IsEditMode).prop("checked")) redrawRepeatingTableEditMode();
});

 

AD. 2- function handling the changes

function retrieveApprovers() {

    var oList = clientContext.get_web().get_lists().getByTitle('ApprovalThresholds');

    var camlQuery = new SP.CamlQuery();
    var locationArr = NWF$("#" + var_Location).val().split(";#");
    var location = locationArr[1];
    var locationCaml = '<Eq><FieldRef Name="Location" /><Value Type="LookupMulti">' + location + '</Value></Eq>';
    var volume = NWF$("#" + var_Volume).val().replace(/[\,]/gi, "");

    if (!volume) volume= 0;

    camlQuery.set_viewXml('<View><Query><Where><And>' + locationCaml +
        '<Leq><FieldRef Name="Threshold" /><Value Type="Number">' + volume+ '</Value></Leq>' +
        '</And></Where>' +
        '<OrderBy><FieldRef Name="Title"/><FieldRef Name="GroupOrderNo"/></OrderBy></Query></View>');
   
    this.collListItem = oList.getItems(camlQuery);

    clientContext.load(collListItem);

    clientContext.executeQueryAsync(
        Function.createDelegate(this, this.onQuerySucceeded),
        Function.createDelegate(this, this.onQueryFailed)
    );
}

 

What id does, is gathering information from the form and construction of a CALM query, that it sends to SharePoint to get a list of approvers. If it succeeds it triggers the "onQuerySucceeded" function.

 

What that function does is making a loop through each returned row.

Then, for each approver (as there may be more than one) it calls SharePoint endpoint for additional information (like login or email):

 

function onQuerySucceeded(sender, args) {
    // Redraw the existing table, remove everything what exists, leave fresh instance
    redrawRepeatingTable();

    var listItemEnumerator = collListItem.getEnumerator();

    while (listItemEnumerator.moveNext()) {
        var oListItem = listItemEnumerator.get_current();

        var approvers = oListItem.get_item('Approvers');
        var approvalOrder = oListItem.get_item('GroupOrderNo');

        NWF$(approvers).each(function (idx, obj) {
            var person = JSON.stringify(obj);
            person = JSON.parse(person);
            // get user's display name and ID
            var approverId = person.$1T_1;
            var approverName = person.$4K_1;
            var userData = "";

            // ask for users additional data
            NWF$.ajax({
                url: siteurl + "/_api/web/getuserbyid(" + approverId + ")",
                method: "GET",
                async: false,
                headers: { "Accept": "application/json; odata=verbose" },
                error: function (data) {
                    console.log("Error: " + data);
                }

Once it gets it (done) it pushes the information to the last, found row (.nf-repeater-row:last) using the '.approvers' class as the selector for the repeating field control.

This is a key point here. The class name is the only way for the script to reach the control and then its contents.

If the "hideNativeRepeatingSectionControlls" is set to true, it also removes the "X" icon from the row, so that it cannot be deleted using the UI. It also covers it with the overlay, so the user won't be able to change the values.

You cannot set fields to be disabled or hidden using the CSS or Forms rules, as the hidden or disabled fields, for some reason, are not being taken into consideration during the form saving. So if you put a value into such field, that value won't get saved to SharePoint.

Instead use "visibility:hidden" (rather than "display:none") and a calculated field or overlay to make a field "disabled".

After it fills all the field in a row it simulates the "click" on the "add row" link that is underneath the repeating section, to create a new, blank row:

    }).done(function (userData) {
                NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo input').val(approvalOrder);
                NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo input.nf-associated-control').attr("style", NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo input.nf-associated-control').attr("style") + "background-color: transparent !important;");
               
                NWF$(".approvers .nf-repeater-row:last").find('.approversApproverEmail input').val(userData.d.Email);
                NWF$(".approvers .nf-repeater-row:last").find('.approversApprover input').val(approverName);
                // remove image for row deletion
                if (hideNativeRepeatingSectionControlls) NWF$(".approvers .nf-repeater-row:last").find('.nf-repeater-deleterow-image').css("visibility", "hidden");

                // append overlay to avoid editting ;) fields must be enabled to allow proper save
                if (hideNativeRepeatingSectionControlls) NWF$(".approvers .nf-repeater-row:last").append('<div class="approverOverlay"></div>');

                //add next row
                NWF$(".approvers").find('a').click();
            });
        });
    }

Then it removes the last, empty row, as it will always be added. It also adds, to every row generated by the process an additional class "toRemoveOnReload" so that the "redrawRepeatingTable()" function will know, what should be deleted, once the repeating section requires to be re-created.

    // remove last, empty row, as it is always empty
    NWF$(".approvers .nf-repeater-row:last").find('.nf-repeater-deleterow-image').click();

    // mark all additional rows as to be removed once control requires redraw:
    var addedRowsSuffixes = NWF$("input[name$='InternalRepeaterAddedRowSuffixes']").val().split(",");
    NWF$(addedRowsSuffixes).each(function (key, val) {
        NWF$("div[name='" + val + "undefined'").addClass("toRemoveOnReload");
    });

    return true;
}

The redrawRepeatingTable() function looks like this:

//function used to delete existing rows in repeating table leaving it as new
function redrawRepeatingTable() {
    //delete all existing repeating table rows, then build them again
    NWF$(".approvers .toRemoveOnReload").each(function () {
        NWF$(this).find('.nf-repeater-deleterow-image').click();
    });

    NWF$(".approvers .nf-repeater-row:last").find('.approversOrderNo input').val("").css("background-color", "rgb(248, 248, 248) !important");
    NWF$(".approvers .nf-repeater-row:last").find('.approversApprover input').val("");
    NWF$(".approvers .nf-repeater-row:last").find('.approversApproverEmail input').val("");
}

The last function, that is called redrawRepeatingTableEditMode() is used to inject suffixes and the "toRemoveOnReload" classes to the loaded repeating section control, generated when form is displayed in edit mode:

//function used to enchance table of approvers created in the edit mode:
function redrawRepeatingTableEditMode() {
    var suffix = 1;
    var suffixes = "";
    NWF$(".approvers .nf-repeater-row").each(function () {
        NWF$(this).find('.nf-repeater-deleterow-image').css("visibility", "hidden");
        // inject prefix into div's ID'
        if (suffix > 1) {
            NWF$(this).attr("id", suffix + "_" + NWF$(this).attr("id"));
            NWF$(this).attr("name", suffix + "_undefined");
            suffixes += suffix + "_,";
        }

        //increment prefix value
        suffix += 1;
    });

    // inject suffixes into the dedicated field
    NWF$(".approvers").find('.nf-repeater-addeddrow-suffixes').val(suffixes.substr(0, suffixes.length - 1));
    var addedRowsSuffixes = suffixes.split(",");
    NWF$(addedRowsSuffixes).each(function (key, val) {
        NWF$("div[name='" + val + "undefined'").addClass("toRemoveOnReload");
    });
}

Note that the Repeating Section is holding "suffixes" of each added row in a hidden field named  "InternalRepeaterAddedRowSuffixes". The string is built using the pattern: #_;#_;#_ where # is next number, counting from 1. You can also note, that each row in repeating section has a name, starting from the suffix and "undefined" token. That is another way you can iterate them

Summary

This way of building dynamic repeating sections doesn't need only to be used for gathering approvers. You can use it to get any kind of dynamic sets, like products, parts (depending on a chosen product) etc... I see a lot of possible use cases

 

I have attached my exported form and the JavaScript to the post. Enjoy!

cazza162

Print friendly Nintex Forms

Posted by cazza162 Champion Sep 11, 2017

Without having Nintex Forms Enterprise and the handy "Print to PDF" functionality, we often spend a lot of time on workarounds for this.  My good friend and colleague Gary Powell-Jones came up with this solution that he has allowed me to share with you all:

Print friendly Nintex Forms

Designing the form

The form can be designed to allow items to not be printed (e.g. appear only on screen) or appear only when printed (such as a disclaimer).

For print only items, add a css class of printonly to the control or element

For no print items, add a css class of noprint to the control or element

Note that the JavaScript below will work even if there are no controls or elements with these css classes

Form custom JavaScript

Include the following snippet in the form custom Javascript. It adds a function called ‘PrintFormHtml’ to print the form, a function to hide print only elements when the form is initially loaded.

 

function PrintFormHtml(){

 NWF$('#suiteBar').hide();

 NWF$('.noprint').hide();

 NWF$('printonly').show();

 window.print();

 NWF$('#suiteBar').show();

 NWF$('.printonly').hide();

 NWF$('.noprint').show();

 return true;

}

 

NWF.FormFiller.Events.RegisterAfterReady(function () {

  NWF$(document).ready(function () {

   NWF$('.printonly').css('display','none'); //THIS HIDES PRINT ONLY ELEMENTS

  });

});

Print Button

Add a button to the form, using the JavaScript action. The action will be PrintFormHtml();. Optionally, the button can be made visible on the SharePoint ribbon using the standard Nintex settings

Operation

When the button is clicked it

  • hides the suitebar
  • hides items with the CSS class of ‘noprint’
  • shows items with the CSS class of ‘printonly’
  • calls the printer dialog

 

After printing, it resets the form:

  • showing the suite bar
  • hiding the print only elements
  • showing the no print items

Hi all,

 

during last years, several times I've encountered projects when the best suitable action in order to ask a user to do something in a workflow was a Flexi task action with just one outcome..

 

If the customer is using also Nintex Forms and because Outcome is a mandatory field, their following question is always: "Is it possible to autoselect the only option?" and "Is it possible to make it hidden?"

 

Until the use of the new Responsive Designer (at this moment available only for Nintex for O365), the only option in order to achieve this is the use of javascript, and I want to share with you how I do this:

  1. Add a class to the decision field (in my case "decision")
  2. Go to Form Settings and in Advanced Javascript put the following script:

NWF$(document).ready(function(){
NWF$('.decision input').attr('checked','checked');
//NWF$('.decision').hide(); //remove comments if you want to hide the control
 });

With the above script, the option inside the element with "decision" class will be selected, in case you want also to hide it, you can remove the comment on last line so it will be hidden from form..in this case you can also remove the corresponding label and panel (think about the Delegation link) in order to reduce the space of the form, just move the control somewhere in the form, also overlapping some other fixed control (e.g over the logo), just to keep it in the form but without occupying additional space.

 

Hope this post may help someone and make him/her save some time..

 

Giacomo

Welcome to our monthly mention of noteworthy community contributors!

 

In May, we started a new way of highlighting people you should probably be following in the community.  It's a great way to really get a sense of their contributions.

 

Each month, I name 10 people to the Honor Roll, and ask you to visit their profile and then "follow" them to spark connections.  This month, I wanted to point out that we have a mix of community members and some Nintex Technical Evangelists!

 

Richard Ruth is a SharePoint developer who's created some great blogs recently. And Eric Rhodes is a long-time member who regularly shares his knowledge here and in attending our annual conference. Mike Oryszak is a senior solutions architect who freely offers good advice in a friendly manner. I love his helpfulness. And Paul Crawford is a freelance SharePoint consultant and Blue Ribbon Group member in the community who is always willing to get his hands dirty to help someone.

 

William Knowles, Jaimé Seita, Terry Simpson and Gonzalo Marcos are Nintex Technical Evangelists whose writing you are going to see a lot more of in the community. If you like knowing the minute someone posts useful info, follow them!

 

Here's how: Visit each of their profiles and click "follow," which is just to the right of their smiling profile photo.  Here's an example:

euanprofile

 

Why do this?  Because following someone puts their community activity in the news stream of your choosing and exposes you to what they're doing in the community.

 

This month's Honor Roll members:

honorrollHonor Roll

Mike Oryszak 

Paul Crawford

Lachlan Ainley (Hawkeye Product Marketing Mgr)

William Knowles (TE)

Jaimé Seita (TE)

Eric Rhodes

Richard Ruth

Matt Jennings (Forms and Mobile Product Marketing Mgr)

Terry Simpson (TE)

Gonzalo Marcos (TE)

 

 

honor roll big

 

 

Honor Roll members will get this badge in their reputation center, along with 100 points.

 

If you'd like to nominate someone for the honor roll next month, post their name below and tell us why you think they should have a bigger following!

Filter Blog

By date: By tag: