Episerver - update 360

Precondition:

There is a profile filter definition which has at least one param in the query, like this one:

        {
            "Id": "fd_PDF_Name_eq",
            "Name": "PDF_Name_eq",
            "Description": "Name equal inputValue",
            "Query": "Name eq {{name}}",
            "Parameters": {
                "name": "string"
            },
            "Category": "Profiles Category",
            "Type": "Profiles"
        }

Steps to reproduce:

1. Access to Insight > Segment > and click on Create a Segment button.
2. Choose the filter definition in the precondition and insert the param name like: test 01.
   • Expected result: Returns only the profiles with name test 01.
   • Actual result: Returns many profiles which names do not have test 01.
3. With the same filter definition, insert param name with value in double quotes like "test 01" - it returns the correct profile.
   If you click Save segment in step 2, this segment will have many profiles without test 01 in the name (exactly the number of profiles that are returned in step 2).
   Note: The same bug occurs if you insert parameter with value: test 00, but not for parameters test 02, test 03, test 04.

Marketers can now set the time or/and count metrics when creating a segment based on event filter definitions, and reuse the same filter definition in combination with the time period and the number of event occurrences.

Precondition:

Create profile test@test.com with Payload info like this:

"Payload": {
     "number": 2
}

Steps to reproduce:

1. Using API, create a segment with ProfileQuery being Payload like this one:

   {
     "Scope": "default",
     "SegmentManager": "admin@example.com",
     "ProfileQuery": "Payload.number eq 2",
     "AvailableForPersonalization": true,
     "Archived": false,
     "FavoredBy": [
       "string"
     ],
     "Name": "Payload",
     "Description": "Payload"
   }
   

1. Create a Visitor Group for the segment in step 1.
2. Set personalize content for Visitor Group in step 2.
3. Log in to the site with profile test@test.com and view the personalize content.

Expected result:

The user can see the personalized content.

Actual result:

The user cannot see the personalized content.

Create a new profile filter definition with an invalid property (which does not belong to the profile) in Query like this one:

POST: /api/v2.0/FilterDefinitions
{
    "Name": "Testing_VisitorGroup_input_value",
    "Description": "VisitorGroup with inputValue",
    "Query": "Testing eq {{value}}",
    "Parameters": {
        "value": "string"
    },
    "Category": "Profiles",
    "Type": "Profiles"
}

Expected result:

Returns 400 Bad Request with message Invalid filter definition.

Actual result:

Returns 201 Created and create new filter definition successfully.

The same thing happens if you create an event filter definition with an invalid property which does not belong to the track event.

Steps to reproduce:

1. Create a segment that includes more than 10 profiles.
2. Get all profiles and emails that belong to the segment (they are less than 500 records), do MatchByProfileId or MatchByEmail

POST: segmentURL/segmentId/MatchByProfileId 

Expected result:

All the profiles based on profileIds/Emails should be returned.

Actual result:

Only 10 profiles are returned.

An indication/warning is now displayed in the user interface when a metric is not applicable with the selected filter definition.

Steps to reproduce:

Execute an invalid query using the event preview endpoint, for example:

Events | summarize count() by Payload

Expected result:

Specific error message with details of what is wrong and ideally suggests how to fix the problem.

Actual result:
Generic error response is displayed, like this:

{"error":{"code":"400","message":"Failed to execute the query.","target":"","details":[]}}

Steps to reproduce:

1. Create a new segment with event/profile filter definition without Query property in Filters:

{
  "Scope": "default",
  "SegmentManager": "Franklin Cummings",
  "AvailableForPersonalization": false,
  "Archived": false,
  "FavoredBy": null,
  "Name": "Testing Segment",
  "Description": "Testing Segment",
  "Filters": {
    "Items": [
      {
        "Type": "Events",
        "Parameters": {   
          "value": "home"
        }
      }
    ]
  }
}

Expected result:

Returns 400 Bad Request with Validation Error.

Actual result:

Returns 500 Internal Server Error.

Only shared filter definitions compatible with currently installed products are displayed.

Based on profiling data, StickySiteKpi can allocate a lot of objects and cause frequent GC gen 0.

Steps to reproduce:

• Create a form that contains a Rich text element.
• Cut that element under For This Form folder and paste it into another folder.
• View the page that contains the form.

Expected result:
The page shows the form without any problems.

Actual result:
A NullReferenceException has been thrown.

Submitted form events have been updated to support doing asynchronous calls before submitting data.

The ExpiredFormSubmissionRemoveJob loads all existing forms before performing a delete action on expired forms. This may cause performance issues if there are a lot of submitted forms.

CleanupPartialSubmissions() incorrectly collects and removes both partial AND finalized submissions.

Steps to reproduce:

1. Create a form with 2 elements and make the second element show if the condition is met on the first element.
2. Export the page with the form to a file.
3. Change the name of the first element in the form.
4. Import the form without updating existing content.
5. Go to the dependencies tab in the second element of the imported form.
6. The dependency has a crisscrossed background and the name of the dependent form element is the name of the changed element from the first form. 

Expected result:

Form field dependencies should work.

Actual result:

Dependencies for form elements do not get imported correctly and do not work. In the Dependencies tab in the imported form, the second text element's dependency points to the first text element in the original form.

The default controller can be overridden by editing the default coreController="/EPiServer.Forms/DataSubmit". This does not apply to the Hidden visitor profiling regarding the GetGeoData() method from the controller, since the URL used for calling that is hardcoded in the client resource javascript (EPiServerForms.js). A fix should be made here to get control of the GetGeoData and to be able to really customize the functionality.

Steps to reproduce:

1. Create a page in SV language that contains a form container.
2. Submit form.

Expected:

The text "The form has been submitted successfully." is translated correctly.

Actual:

The text "The form has been submitted successfully." isn't translated correctly in Swedish. It still displays: "Formuläret skickat.", which is the old translation and not the latest.

A/B testing preview displays squashed text.

A default set of filter definitions are now included out of the box in Visitor Intelligence. Marketers can create segments based on Commerce events and profiles without asking developers to create their own filter definitions.

1. Create a new profile:

POST: /api/v1.0/profiles
{
    "Info":
    {
        "ZipCode": null
    }
}

-> It returns 201 Created with body:

{
    "ProfileId": "545db9d4-79f8-49cb-ae63-34ab6ca95647",
      .....
    "Info": {
        "ZipCode": null
     }
}

2. Get the newly created profile in step 1:

GET /api/v1.0/profiles/default/545db9d4-79f8-49cb-ae63-34ab6ca95647

-> It returns the profile with info:

 {
     "ProfileId": "545db9d4-79f8-49cb-ae63-34ab6ca95647",
     .....
     "Info": {},
 }

Expected result:

The Info property should display consistent information.