Contents x
    Release 4.18.0 (2021-08-06)
    • 24 Aug 2023
    • 4 Minutes to read
    • Contributors
    • Print
    • Dark
      Light
    • PDF
    Contents

    Release 4.18.0 (2021-08-06)

    • Updated on 24 Aug 2023
    • 4 Minutes to read
    • Contributors
    • Print
    • Dark
      Light
    • PDF
    Article summary

    Release 4.18.0 (2021-08-06)

    This update primarily effects SharePoint Modern View, but the same underlying code is used in all SharePoint products.

    Fix: Correct missing obfuscation of sensitive data

    Update code to continue obfuscation of parameter list when encountering an error (Issue 1758, 1727)
    When obfuscation is enabled the code will iterate through the parameter list and obfuscate the parameter value with an MD5 hash. In rare cases the loop would prematurely exit due to an error, resulting in some parameters not receiving a hashed value. This update ensures all parameters are tested even if errors arise in one parameter, and sets values to an empty string if the MD5 hash experiences an error on a given parameter effectively removing it from the hit.

    Fix: Correct lack of Web Part Name on click events to Modern web parts

    Update code to recapture Web Part Name on clicks after changes to web part HTML from MS (Issue 2699)
    Detection of which web part was clicked requires searching up the DOM to find specific HTML attributes, and then tying this back to known web parts on the page. After changes by MS to the HTML format of web part containers in the Modern View, the ability to detect which web part was clicked was lost. This update restores this capability for current web parts and attempts to avoid the issue in future if some attributes change.

    Fix: Correct lack of Web Part data on page load events in Modern "Repost Pages"

    Update code to gather web part data for Repost Pages where normal API methods return no results. (Issue 2728)
    Collection of web part data for a page is accomplished via an API call to SP to request the information. Repost Pages are links to other article pages and do not return web part data with the typical API call. An alternative method was implemented for Repost Pages and collection of web part data was restored. This also restores lost click tracking data for Repost Pages related to Issue 2699.

    Fix: Correct unexpected Modern Article parameters on some click events

    Update code to avoid passing unexpected WT.article parameters on clicks to some links such as navigation menus (Issue 2819)
    Detection of clicks to an article in a News web part was incorrectly allowing some WT.article parameters to be sent on clicks to non-article related links. This update corrects the detection and ensures that the WT.article parameters are only passed on the click to a News web part link, or on the page load of an Article (and Repost Page) page.

    Fix: Correct lack of Article parameters on Modern Repost Pages

    Update code to detect Repost Pages and pass appropriate WT.article parameters (Issue 2820)
    Adding an article to a News web part manually marks the article as a Repost Page and some of the underlying metadata to identify it as an Article page changes. The SP server redirects users to the real Article page content. This update adds Repost Page detection and classifies it as an Article so the WT.article parameters are collected for the page as it would be if the real page was loaded.

    Enhancement: Collect user defined name for Web Parts in Modern view

    Update code to collect user defined titles for individual web parts in modern pages (Issue 2694)
    This update adds the ability to collect the user defined Title for a web part and fall back to the default title if not configured on the page. This feature allows reports to show data for each web part when more than one of the same type of web part is displayed on a given page. In previous releases Webtrends was only able to capture the default title for the web part, and offered an option to append the Web Part Instance ID to the name to help differentiate these in reports. Going forward customized names of web parts will be displayed instead and the web part instance ID is no longer required. In Classic View the collection of user defined titles was already the default behavior.

    Note: This enhancement will cause data in Web Part reports to split after deployment.

    Historical data will show the real web part title, while newer data will use the user defined web part title or the default title.

    Enhancement: Track Modern view Events web part

    Update code to track clicks to Events web parts and collect additional data for clicks and views of an event page (Issue 2699)
    The Events web part contains no links and the default "All click tracking" code was unable to detect clicks to an event. This update adds tracking of the event tiles as well as the Add to my calendar button. The Events.aspx page list of events will also track the same as the Web Part. The page load of a specific event will also send the additional data as well as wait for the list item to load to capture the event's title. New parameters included in this release are:

    • WT.shp_event_title = Event Title
    • WT.shp_event_date = Event Date e.g. Jun 5-Jun 6
    • WT.shp_event_time = Event Date and Time e.g. Fri, Jun 25, All day
    • WT.shp_event_category = Event Category e.g. Meeting
    • WT.shp_event_location = Event Location e.g. Virtual Meeting or a physical address
    • WT.shp_event_action = View (view event page), Click (web part click), or Add (Add to my calendar)

    Note: It is not currently possible to capture an individual event's "ItemId" parameter on the click to the web part or an Event lists tile as the required data is not avialable in the page. The ItemId parameter will be present on the view of the Event's page.

    Was this article helpful?
    What's Next