Showing posts with label Conditional forms. Show all posts
Showing posts with label Conditional forms. Show all posts

Wednesday, April 27, 2016

Providing different forms for different users in SharePoint Online

If you want to create different forms to different types of users in Forms Designer for SharePoint Online, you have two options: use permission settings or use SharePoint groups. We’ll look at both options in this article.

Suppose we have two types of users on our SharePoint website: managers and regular users. Managers have elevated privileges and we want to give them a particular set of functionality in a form. And regular users should receive a smaller or a different set of functionality and we want to give them a default form.

What we will do first is create an additional form set for managers using the plus button in the top right corner of Forms Designer.

Adding multiple form sets for a SharePoint list

Using permission settings

SharePoint has inbuilt permissions that we will utilize to distinguish managers from non-managers. Please check this list to see the available permissions:
https://msdn.microsoft.com/EN-US/library/ms412690.

We will pick CreateGroups to differentiate managers from non-managers, as only managers are allowed to create groups on our website.

We then will add an html control onto the default form in Forms Designer and paste the following html code inside it:

<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="CreateGroups" EmitDiv="true">
<script type="text/javascript">
    fd.openForm('fd_Item_52b1ac46-b55e-4d3c-9807-dec2a57b2e9f_EditForm.aspx');
</script>
</Sharepoint:SPSecurityTrimmedControl>
Using SPSecurityTrimmedControl in a SharePoint form

We have used CreateGroups permission string and the name of the form where we want our managers to be redirected to. The name of the form can be seen if you go to the appropriate form set in Forms Designer (in our case it’s Manager) and pick the appropriate form (in our case it’s Edit Form). That is the form that managers will be redirected onto:

SharePoint form filename

Now whenever a manager opens the default edit form he or she will be redirected to his manager-only form, while a non-manager will stay on the default form.

Using SharePoint groups

Another choice we have to set up user group specific forms is by utilizing SharePoint groups.

For this we’ll need to add a JavaScript script to document library. Create a file named redirect.htm and add the following code to it:

<script type="text/javascript">
ExecuteOrDelayUntilScriptLoaded(function () {
 fd.openForm('fd_Item_ee433778-833d-4154-a72f-f68dc876fdc5_EditForm.aspx');
}, 'plumsail.fd.core.js');
</script>

Again, you’ll need to replace the filename as before.

Upload redirect.htm to a document library on your website. Take note of its URL.

Now to go the list with your form sets. Click to edit one of the three forms, we’ll be editing the Edit Form.

Editing SharePoint form page

You’ll be redirected to the default edit form in edit mode, click “Add a Web Part” and add a Content Editor webpart:

Adding Content Editor Web Part to a SharePoint form

Click the Content Editor Webpart’s little arrow button and click Edit.

Enter the URL of redirect.htm into the box:

Setting Content Link property of the Content Editor Web Part

Expand Advanced and enter the SharePoint group members of which you want to be redirected to the additional edit form, in our case it’d be the site collection owners that will be redirected to the Manager edit form:

Settings Target Audiences property of the Content Editor Web Part

Click OK.

Now all members of the group will be redirected to the Manager edit form, while non-members will stay on the default form.

Thursday, July 9, 2015

Passing and getting Date object to and from date and datetime fields

Another new feature we introduced in FormsDesigner 3.0.1 is the ability to interact with date and datetime fields by passing JavaScript Date objects. This feature takes away the need for consumer to think about parsing dates in locale specific formats and simplifies the way date operations are performed on date/datetime fields. Let us take a look at the following use case.

SharePoint issue form

Here we have our old form for creating new issues. Suppose the priority of an issue we set affects the due date for its resolution: high priority implies that the issue is to be resolved within two days, normal priority implies a 5 day period and low priority leaves the due date undefined.

Because the due date periods are pre-defined and are standard for all issues, we want to auto-assign them based on the priority we set. Here’s how we’ll go about doing it: get the current Date object, add the required number of days to it and set the object to our Due Date field.

This is the code we added to our form to achieve this effect:

function setDate(){
    var date = new Date();
 
    switch (fd.field('Priority').value()) {
        case 'High':
            date.setDate(date.getDate() + 2);
            break;
        case 'Normal':
            date.setDate(date.getDate() + 5);
            break;
        default:
            date = null;
    }
 
    fd.field('DueDate').value(date);
} 

setDate();

fd.field('Priority').change(setDate);

What this code does is:

  1. It defines setDate() method which:
    • Creates a Date object which is initialized with the current date.
    • Checks the value inside the Priority field and depending on it, gets the current date value and adds the respective days offset value.
    • Sets the resulting date object to the field.
  2. It calls the setDate() method when the form is loaded.
  3. And it defines a change event, which calls the setDate() method whenever the Priority value changes.

Now, after we’ve saved our form, we can open it up and see how it works.

Whenever we change the priority value, the due date is automatically readjusted:

SharePoint high-priority issue

High priority.

SharePoint normal-priority issue

Normal priority.

SharePoint low-priority issue

Low priority.

Note

This approach is particularly advantageous if your form is potentially browsed in environments with varying locales, as different locales mean different date formats, which our JavaScript functions take care of.

Wednesday, July 8, 2015

Designing custom forms for smartphones, tablet devices, and regular PCs

Today we’d like to introduce you our new Forms Designer 3.0.1 feature for building custom forms for various types of devices, be it mobile phones, tablets or regular PCs. For all these types you can now create separate Display, New and Edit forms which enables you to customize the way different devices view your website. Let’s take a look at a use case.

Say we have a form that looks like this:

SharePoint form for PC

Navigating such form on a mobile device would be pretty cumbersome, as you can imagine. What we need to come up with is something that looks more like this:

SharePoint form for mobile device

How can we achieve this? The short answer would be to use features introduced in Forms Designer 3.0.1:

  • fd.isMobileDevice() and fd.isTabletDevice() JavaScript functions
  • IsMobileDevice and IsTabletDevice Group values (available only in On-Premises version of SharePoint).

Before we proceed, however, we need to turn off the SharePoint site feature called ‘Mobile Browser View’ as it’s not compatible with Forms Designer. To do this go to Site Settings → Manage site features (under Site Actions) → click ‘Deactivate’ against ‘Mobile Browser View’.

Let us look at a how we would utilize these features for our use case in both versions of SharePoint.

Designing for mobile devices in SharePoint Online

In Forms Designer for SharePoint Online we have form sets, meaning we can create any number of forms for each of the SharePoint form types (Display, New, Edit). Utilizing our fd.isMobileDevice() and fd.isTabletDevice() we can check if our user agent requires a mobile version of our form and redirect him to it.

Our initial form in Forms Designer:

Design of SharePoint form for PC

Let us add a new form set for ‘New Form’ called ‘Mobile’. To do this, click the ‘+’ button in the top-right corner of the window and get the following dialog:

Form set for mobile devices

We’ll enter ‘Mobile’, click OK.

Here we can design a mobile device-friendly version of our form (don’t forget to click ‘Save’, navigating to another form will cause your changes to be lost):

Design of SharePoint form for mobile devices

What we’ve done here is created a miniature version of our logo, brought out required fields onto the main window to allow for a simpler fill-in process, replaced the tab control with an accordion and made the whole form is fit a regular sized smartphone (by placing everything inside a table and setting the table’s size – which is also a new feature of 3.0.1).

Before we go further, look at the bottom-left corner of the window where it says ‘File: xxxxxx.aspx’. Take a note of this filename, we’ll need it later when we write our JavaScript code.

Now that we have designed our mobile version of the form we need to implement the redirect logic. Let’s go back to our default ‘New Form’ and open up the JS editor. This is the code we will add:

if (fd.isMobileDevice() || fd.isTabletDevice())
{
    fd.openForm('fd_Item_e05e9ae8-7eaa-49da-9ad0-0b2fe258e719_NewForm.aspx');
}

What we’re doing here is:

  1. Checking if the user is on a mobile device or tablet with fd.isMobileDevice() || fd.isTabletDevice().
  2. If he is, we’re opening the appropriate form by specifying the filename we have copied above in fd.openForm(filename).

After we’ve pasted in our code with the appropriate filename and saved our form, we’re done. What will now happen is every time a user clicks ‘Add new item’ he will be redirected to a mobile version of the ‘New Form’ if he’s using a mobile phone or a tablet (and if he’s not using a mobile device, he will stay on the initial desktop-friendly form).

The very same procedure would be used if we were creating mobile versions of ‘Edit’ and ‘Display’ forms.

Let’s now have a look at how you could achieve the same thing in SharePoint On-Premises.

Designing for mobile devices in SharePoint On-Premises

The procedure for providing desktop and mobile device versions of a form is even simpler in SharePoint On-Premises: you don’t need to write custom JavaScript code to redirect the user, you can use IsMobileDevice and IsTabletDevice group tokens instead.

Let’s open up the ‘New Form’ form in Forms Designer. We will use exactly the same set-up shown in the previous section.

What we’ll do is add a new group by clicking the ‘+’ button in the top-right corner of the window.

Group of SharePoint forms for mobile devices

We’ll call this group ‘Mobile’ and in ‘User-defined rule’ tab we’ll add the following code:

IsMobileDevice || IsTabletDevice

Click ‘Validate’ and ‘OK’.

A new form will be created as a copy of the desktop form. We’ll change it to make it look the way we want, as shown in the previous section.

Click ‘Save’, and we’re done. Now whenever user wants to add a new item he will be directed to the appropriate form, depending on the type of device he’s using.

Wednesday, July 30, 2014

How to conditionally hide, disable, and make mandatory fields on SharePoint forms dynamically

Here I'd like to demonstrate the most popular cases you may face during implementation of SharePoint forms with complex logic. Most likely you will need to combine the cases described below to cover your requirements but it's quite easy if you have enough samples. To accomplish the tasks below I used SharePoint Forms Designer 2.8.10. All samples work properly for all editions of SharePoint 2010/2013 including Foundations and Office 365.

First of all, I'd like to make an important notice which is common for all the cases. fd.field() method of JavaScript framework expects an internal name of a field you want to retrieve. As you might know, it's not easy enough to obtain an internal name of a field in SharePoint, so we included this property into field properties in Forms Designer 2.8.10:

Internal name of SharePoint field

Now you can just copy and paste it into your code in a much simpler way even without closing Forms Designer. OK, let me start.

Prepopulate field and disable/enable it based on condition

Let's say we have a task form and we need to set the Percent Complete to 100% and disable it when the user turns the Status field into Completed:

SharePoint conditional fields

We should place the following code into JS-editor of Forms Designer:

function setPercentComplete() {
    if (fd.field('Status').value() == 'Completed') {
        // Setting the Percent Complete to 100
        fd.field('PercentComplete').value('100');

        // Getting JQuery-object of the field and disable it
        fd.field('PercentComplete').readonly(true);
    } else {
        // Getting JQuery-object of the field and enable it
        fd.field('PercentComplete').readonly(false);
    }
}

// Calling setPercentComplete when the user changes the status
fd.field('Status').change(setPercentComplete);

// Calling setPercentComplete on form loading
setPercentComplete();

// Enabling fields before the submission
fd.onsubmit(function () {
    fd.field('PercentComplete').readonly(false);
    return true;
});

Please, pay attention to the last part of the code:

// Enabling fields before the submission
fd.onsubmit(function () {
    fd.field('PercentComplete').readonly(false);
    return true;
});

Most browsers don’t send values of disabled fields to the server during the submission, so they will be lost. Therefore, we need to enable all fields that we need to save right before the submission in onsubmit handler.

Hide/show field or set of fields conditionally

Now I will modify the script from the previous section so that it will hide the Percent Complete field. First, we should assign a CSS-class to the field to use it in JQuery-selector:

Assign CSS-class to SharePoint field

OK, now we can use it to retrieve the field container by the following way: $('.percent-complete'). Here is the modified code:

function setPercentComplete() {
    if (fd.field('Status').value() == 'Completed') {
        // Setting the Percent Complete to 100
        fd.field('PercentComplete').value('100');

        // Getting JQuery-object of the field container and hide it
        $('.percent-complete').hide();
    } else {
        // Getting JQuery-object of the field container and show it
        $('.percent-complete').show();
    }
}

// Calling setPercentComplete when the user changes the status.
fd.field('Status').change(setPercentComplete);

// Calling setPercentComplete on form loading
setPercentComplete();

Please, notice that I've removed the last part from the code because values of hidden fields are passed to the server properly.

What if we need to hide multiple fields? There are several approaches. You can either put them into a single table and assign CSS-class to the table:

Assign CSS-class to multiple SharePoint fields

Next, use that class in JQuery-selector to retrieve the table and hide or show it:

// Hide the table
$('.fields-to-hide').hide();

// Show the table
$('.fields-to-hide').show();

Or if your fields are scattered about the form and you cannot put them into a single table, you can assign the same CSS-class to all fields that you need to hide e.g. 'field-to-hide' and use it in the selector to make all of them disappear:

$('.field-to-hide').hide();

Require field based on condition

At this section I'd like to demonstrate how to make some fields mandatory based on other field values. Let's go back to the original task form and say that we need to make the Due Date field required if the task is assigned to someone (the Assigned To field is not empty).

Here is the sample:

function setRequiredFields() {
    if (fd.field('AssignedTo').value().dictionaryEntries.length != 0) {
        // Add asterisks
        fd.field('DueDate').titleRequired(true);
    } else {
        // Remove asterisks
        fd.field('DueDate').titleRequired(false);
    }
}

// Calling setRequiredFields when the user changes the assignment
fd.field('AssignedTo').change(setRequiredFields);

// Calling setRequiredFields on form loading
setRequiredFields();

// Custom validation
fd.onsubmit(function () {
    if (fd.field('AssignedTo').value().dictionaryEntries.length != 0) {
        if (!fd.field('DueDate').value()) {
            alert('Please, fill in the Due Date field.');
            return false;
        }
    }

    return true;
});

As you can see, I've added the custom validation into onsubmit handler, whereas fd.field().titleRequired() just adds or removes the asterisk near the title.

Get values on display forms

Finally, I'd like to focus your attention on differences between display and edit or new forms. Display forms don't contain controls, so you can retrieve only the text representation of field values like you see them on a form. The samples above work on new and edit forms only. You should use the following syntax to obtain a text representation of values on a display form:

fd.field('Status').control()._el().text()

Get information on how to get or set values of different types of fields from the following article: http://formsdesigner.blogspot.com/2013/04/getting-and-setting-sharepoint-form.html

Please, feel free to ask your questions in comments.