Title: TeamPage 6.2.41

TeamPage 6.2.41 is focused on bug fixes and under-the-hood improvements to query performance, building on the optimizations and refinements introduced in other recent releases. In addition, Server Settings > Journal Info now shows some useful statistics about the current journal, including the total number of journal entries, total and active user and space counts, and the byte size of the main journal database. This release also adds some Forms Client, SDK/SDL Query, and Database API capabilities that may be of interest to customizers. Please read on for the full list of changes.

Download TeamPage 6.2.41


Table of Contents


Bug Fixes



• Fixed some issues related to TeamPage's native query optimization that could prevent some entries that should have been results from being returned in response to certain queries. (Server92947)

• Fixed an issue that could cause TeamPage's native fulltext searches to include paragraphs containing prefix and suffix matches in cases when only paragraphs containing exact word matches should be included. (The issue would not affect which entries were displayed as hits, but rather only the paragraphs whose content would be used for feed, snippets or brief volume renderings of the entries.) (Server92999)

• Fixed a bug that could cause TeamPage to return results for native queries involving certain combinations of fulltext search terms that are not actually matches. (Server93032)

• Fixed a bug that could cause entries whose original version is rejected or erased from being included in results for certain types of queries, including tag-based queries. (Server87597)

• Fixed a bug that could cause some attachments to become disconnected from an entry or an entry-in-progress if an attachment's file name contained an ampersand and any of the "Insert Image", "Insert Link" or "Insert Widget" dialogs were used in the editor. (Server93025)

• Fixed a bug that could prevent the "Allow Links to This Article by Name" checkbox and the names editor dialog from working properly in TeamPage's web-based forms. (Server92886)

• Fixed a bug that could cause tags removed from a form launched by using the "Copy" action to set up a copy of an entry to "come back" and be applied as tags on the resulting copied entry. (Proteus16107)

• Fixed a bug that could cause some values that had been present when a form was initially loaded, but later removed, to "come back" when a user loads a Work-in-Progress. (Proteus16116)

• Fixed a bug that could cause deleted entries to show up in the results for a query intended to show rejected entries. Although deleted entries are considered rejected, they are not intended to show up among these or any other results. (Server90954)

• Fixed a bug that could cause the last result in a "chunk" to be repeated in certain cases when entry query results are returned in chronological order (oldest entries first). (Server93166)

• Fixed a bug that could prevent type-ahead completion from being able to use a connected external search engine to resolve queries that requested multiple specific types of entries (e.g., milestones and projects). (Server93084)

• Fixed some issues that could prevent TeamPage from gracefully handling errors arising from attempting to modify or access invalidated login session data. Users might not be aware of these errors, but they may occasionally have caused minor and transient issues in environments in which TeamPage is configured to use NTLMv2 to authenticate with a Microsoft Active Directory server. (Server89267)

• Fixed a bug introduced in a recent release that could prevent administrators from viewing the details of security principals, such as those for user accounts or groups defined within TeamPage, if the principal is contained in one or more other groups defined in TeamPage that contain a cycle in their group membership -- for example, if group A contains group B, and group B also contains group A. It is definitely not advisable -- and usually a sign that one or more group definitions need to be changed -- to define groups that contain such cycles, but TeamPage once again gracefully handles such cases in the context of displaying security principal details. (Server93183)

• Fixed a bug that could prevent the creation of entries via TeamPage's SOAP API. (Server93021)

• Fixed a bug that could prevent unexpected errors from being reported when an administrator attempts to deactivate a space or user. (Server93212)

• Fixed a bug that could cause undesired side effects to occur when a user clicked on an authored link to an attachment appearing in the body of an entry. The link would correctly refer to the targeted attachment, but the URL would improperly change, and the page styles would be lost as a result of that unexpected and incomplete navigation. Such links now correctly allow the user to access the attachment without causing this partial and unexpected navigation to occur. (Proteus16161)

• Fixed a minor bug that could cause subsequent chunks of results loaded on a "Discussions" page not to correctly observe certain custom parameters that were manually requested by a user. (Proteus16158)

Improvements



• Optimized the queries used for "Updated" and "Discussions" pages, and the corresponding "Updated" and "Discussions" sections; and optimized the way searches are applied to the results from those queries. Both of these query types now also support the same kind of entry type and author filtering that are supported in pages like Activity > Feed and Activity > Posts. (Server90422 / Server60585)

• Optimized the way that the base result set for tag-driven queries works to remove the possibility of redundant filtering (e.g., of entries that are considered "hidden" or "rejected", when they haven't been explicitly requested). (Server93078)

• Applied further optimizations to the handling of searches applied to native TeamPage queries. Here are two highlights that may be of interest.

- Firstly, for the most common types of queries, TeamPage can now identify many cases in which the presence of certain search terms means that no entries will ever be matched. In those cases, TeamPage will trivially generate an empty result set. This shouldn't apply to properly configured queries, but can be helpful when attempting to set up custom queries that involve search terms, so that users can more quickly establish whether the query is showing the expected results without having to wait for TeamPage to perform possibly expensive queries to find out that there are no results.

- Secondly, and conversely, TeamPage can now identify many more cases in which certain search terms are redundant, and can be safely ignored. In these cases, TeamPage can ignore them by removing them from the query, thus avoiding wasting the time and memory that would have otherwise have been required to apply their effects.

(Server92882 / Server92948)

• Improved the logging of certain types of administrative operations, such as activating or deactivating a space or a user account, or activated draft mode for a particular space. (Server93211)

• server settings > General > Current Journal > Journal Info now shows some basic statistics about the current journal, including the total number of journal entries, total and active user and space counts, and the byte size of the main journal database. (Server93006)

For Developers



Forms Client API



• The data payload passed to Proteus "form-save" event listeners now contains the TractionId information -- both the numeric FQID, as well as the alphanumeric Traction ID "name" rendering. The JSON encoded payload now has the following structure:

{
  form: "[name of the FormFactory configuration]",
  formId: "[DOM ID of the form instance]",
  formProperties: {
    // map of bootstrap properties used to launch the form, including:
    form: "[requested FormFactory configuration name]",
    html: "[requested HTML title of form]", ...
  },
  formState: {
    // snapshot of the current state of the form's effective field values
  },
  resultErrors: {
    // map of details about errors that happened on server, if any
  },
  resultProperties: {
    // contains the updated form properties, which contain information about the result, including, e.g.,
    fqid: [the newly created entry's numeric FQID],
    new_entry_id: "[name rendering of Traction ID]",
    new_entry_url: "[a URL that may be used to navigate to the newly created entry]"
  }
}


(Proteus16105)

Other Client API



• TeamPage's "action regions" now support two new actions. Any HTML element (usually an A tag) can be set up to trigger these actions by adding an rg= attribute, e.g.:

<a href="javascript:void(0);" rg="a#actionName&param1=value1&...">Click Here</a>

This allows SDL designers to trigger TeamPage's built-in client functionality simply by using the appropriate action name and parameters.

The two new actions are:

- searchForm: the "searchFilterForm" action supports opening a filter form like the ones that can be launched via the "Filter" menu that appears near the top corner of many views, allowing the user to apply a filter to the current view based upon whether the entries' values for a particular EntryField match a particular selected value. From SDL, with an EntryField in scope, this could be set up like this:

  <a class="button" href="javascript:void(0);" rg="<htmlattributevalue.encode>a#searchFilterForm&name=some_field,search_filter_mode&display_name=Some Value</htmlattributevalue.encode>">Filter by Something</a>


- refresh: the "refresh" action supports simply refreshing the page the same way that would happen if the user clicked the "Refresh" button that appears near the top right corner of each page. This can be useful in many cases when a browser refresh is not desirable.

(Proteus16124 / Proteus16134)

• The Proteus.refresh function is now available for custom JavaScript code to request that the page be refreshed in the same way that would happen if the user clicked the "Refresh" button that appears near the top right corner of each page. The function has parameters for two optional arguments:

/**
 * @param callback defines functions to call after the refresh
 *     operation completes (see below).
 * @param scrollToTop pass true to cause the frame to be
 *     scrolled to the top of the page after the refresh.
 */
Proteus.refresh = function(callback, scrollToTop);

// Structure of the callback object:
callback = {

  "beforeRender": function() {
    // Called after the request returns, but before returned data are rendered.
    // Return false if the normal rendering should be skipped (afterRender will not be called)
    return true;
  },

  "afterRender": function() {
    // Called after returned data are rendered.
    // No return value is necessary.
  },

  "onFailure": function() {
    // Called if the request fails.
    // Return false if the normal error handling should be skipped.
    return true;
  }

}


(Proteus16125)

SDK/SDL Query API



• As alluded to above, Journal's getUpdated and getActiveThreads methods now support index entry type and author filtering in the same way that's supported for getEntries queries. This means that those same request filters will apply from SDL when using the <entries> tag used with type="updated" or type="activethreads". In that case, the index type filter and/or author filter will be inherited from the currently scoped CJournalRequest, or can be specified via the entrytypesfilter=, authorfiltertype= and authorid= attributes in the same way that applies to type="rchron" uses. (Server90422 / Server60585)

Database API



• The db.update tag now correctly sets the return code indicating success or failure, as well as the details of any error, in the "_dbupdatestatus" and "last.SQLException" variables, respectively, in the current scope. Previously, these values were only set in the child SDL Scope created to isolate the db.update tag implementation, which prevented these values from being available to SDL designers. (Server93119)



Attachments:
teampage_logo.jpg
Article: Customer5206 (permalink)
Categories: :Doc:changelog, :Doc:r62
Date: October 2, 2019; 2:15:05 PM EDT
Author Name: Dave Shepperton
Author ID: shep