Title: TeamPage 6.2.28

This Traction® TeamPage release is focused on a new version of TeamPage's Quality Management solution, Japanese language search, some cleanup of under-the-hood behaviors and developer features related to erasing TeamPage journal entries, and several bug fixes. Please read on for the full list of changes. See also Aug 2018 | TeamPage ISO 2001:2015 Solution adds integrated Risk and Improvement Project Management.

Download TeamPage 6.2




Quality Management Solution



The ISO 9001:2015 specification includes new requirements for risk-based thinking as well as an improvement program. Risk and Improvement replace the concept of Preventive Action in the former ISO 2015:2008 specification. TeamPage's Quality Management solution - developed in partnership with impi! Solutions -  has been updated to improve support for ISO 9001:2015, with Risk Management and Improvement Project management, reporting, and tracking capabilities to deliver a broader and clearer ISO 9001:2015 quality management solution. The TeamPage Quality Management Solution is packaged as a family of integrated plug-ins, templates, and support to help your product or service organization work better using ISO 9001:2015 practices. Please contact sales@tractionsoftware.com if you're interested in trying out this solution.

Search



TeamPage Advanced Search Support for Japanese



We're pleased to announce that TeamPage's advanced search module, based upon Apache Solr, can now be configured to be optimized for Japanese language documents and queries. Solr installers that reflect the Japanese language configuration are not yet available, but the capability is currently available for customers of TeamPage's cloud hosted offering in Japan.

Advanced Search for Type-Ahead Completions



• Most type-ahead completion controls in TeamPage's forms and elsewhere that offer suggestions for entries will now use the preferred external search engine when it's available. This includes many fields in TeamPage's forms, as well as the Child editor and Insert/Edit Link dialog. This applies to TeamPage installations that use the advanced search module, and in which a server administrator has designated the preferred search engine. (Server89373 / Server80356)

Built-in Text Searches



Some capabilities requiring text searches can't make use of the advanced search module, and not all customers have the advanced search module. This release also includes improvements to TeamPage's built-in text search capabilities aimed at improving TeamPage's built-in text search capabilities.

• Processing of text search queries, particularly those that use Japanese or other East Asian languages, has been greatly improved. In particular, several limitations related to query parsing -- the process of interpreting a text query, and breaking it into words that will be used to find matching results -- have been removed. (Server89352)

(If you need help making sure your TeamPage server is properly configured to provide search across a corpus that includes Japanese or other East Asian language content, please create a support request so that we can assist you.)

• The way that text queries are constructed for type-ahead completion searches using TeamPage's built-in fulltext search has also been improved. Several small bugs and limitations have been removed: queries are less prone to failure due to user input, and will give more complete and relevant results, ordered by ranking. Also, queries using quotations to express phrase searches are now supported; and search result hit highlighting should now work properly for all queries. (Server89379)

Bug Fixes



Deleting Entries



• Fixed an issue the "Delete" action that appears on the context menu when viewing a specific version of an entry (in an "Exact Entry" view) from applying just to that version. The "Delete" action now applies to the specific version being viewed, and the text in the confirmation dialog indicates that this is the case. (Proteus15475)

• Fixed a bug that caused the classic Delete dialog to redirect a user to a login form if they tried to delete an entry that has no remaining non-erased versions. In general, entries that are already erased will be ignored in the context of the classic Delete dialog. (Server89114)

Advanced Search



In addition to the other improvements listed above, two bugs affecting advanced search have been fixed:

• Fixed a bug that prevented queries that had at least one search term ending in a colon from working properly. The colon character is usually used to indicate that a search term is scoped to a particular field for an advanced query, so if it appears at the end of a simple text query, it would be illegal if TeamPage didn't escape it before passing the query terms to the external search engine. (Server89500)

• Fixed an issue related to the generation of updated-as-you-type search results. This issue prevented an error message from being displayed when the user typed an invalid query, or when a communications problem or other unexpected issue prevented the query from being executed, which could easily lead to confusion about why search results were not updated. It also caused valid search queries to be executed twice when generating the updated results. Now queries will only be executed once to produce updated-as-you-type search results, and when the query generates an error, the error message will be displayed in place of the results as expected. (Proteus15580)

Other Fixes



• Fixed a bug that could cause certain "Posts", such as User Profile > Posts or Activity > Posts, to show "system entries," such as tag changes or edits. These entries are not supposed to appear on "Posts" pages (they do appear variously in other pages, such as the User Profile > Feed or Activity > Feed). (Proteus15521)

• Fixed a bug that could cause the wrong completion result to be displayed when searching for an entry by its ID in certain cases, including the "Children" dialog used to create parent-child relationships among entries. The ID of the latest edit would be displayed instead of the original entry ID, preventing the correct entry from being referenced in these cases. (JPBO20149)

• Fixed a bug that could cause non-ASCII characters to be removed from file names when using the "Download" link or button for individual files. (Proteus15464)

• Fixed an issue that could, in certain cases, cause various TeamPage features not to work properly if an administrator attempting to bind a TeamPage user account to an externally defined account (e.g., in a Microsoft Active Directory server) enters an invalid account security principal encoding. Now, regardless of what sort of invalid account security principal encoding has been specified for the external account, TeamPage's ACLs and Groups management dialogs and other administrative features should still function normally. Users with invalid security principal bindings will still not be able to log in until their account settings are fixed, but at least administrators will be able to access the features required to do so. (Server89179)

• Fixed a minor bug that caused the HTML for the user Email Addresses setting to be displayed as text. (Server89182)

• Fixed a bug that prevented some low-level cleanup of incoming content from being applied on edits. The normal "Rich Text Content" cleanup was still applied; only the "Journal Posts" cleanup was skipped. (Server89207)

• Fixed a bug affecting TeamPage's "Manage Trust Store" dialog that caused placeholder text "#$feedback$" to appear in the dialog instead of error or warning messages that might appear as a result of various conditions. (Server89560)

• Fixed a bug that could prevent TeamPage from correctly handling certain invalid request paths. TeamPage now handles these requests more gracefully, with an HTTP 404 response code (or otherwise appropriate response code) rather than an HTTP 500 response code indicating an internal server error. (Server89268)

• Fixed a bug that could prevent suggestions from being offered in TeamPage's Email Articles form's To, Cc and Bcc fields in certain cases. (Server89497)

• Fixed two bugs that could prevent filtering from working properly for certain kinds of tag fields when either clicking on a "drill down" link in a section table or using the filter form via the "Filter" menu. (Server89510 / Server89528)

• Fixed an issue that could, in rare cases, cause unexpected errors for administrators who are trying to test directory service integration settings. (Server89211: Avoid any possibility of null result in UserDirectoryTester)

Internationalization



• Internationalized some place-holder text used in the discussion widget, which can be embedded in other web pages to facilitate discussion within TeamPage. (Proteus15394)

• Changed the way that TeamPage's in-page dialog boxes respond to the enter key so that if a user is using an IME to enter text for a prompt (e.g., renaming a file in TeamPage's document management UI), pressing the Enter key to accept a suggestion from the IME will not also submit the dialog. (Proteus15495)

Other Improvements



• Updated the version of Apache Derby that ships with TeamPage to 10.14.2.0 from 10.14.1.0. See db.apache.org/der… for notes on this Derby release.

• Optimized the way the "Completed Tasks", "Total Tasks" and "% Tasks Complete" values are computed for projects and milestones. These can be displayed in section tables and some add-on modules. (Server89396)

• Fixed the way TeamPage logs certain types of "unexpected" errors for GWT-driven RPC HTTP APIs. This will only generally be triggered by response write failures, which can happen if the connection to the client is lost while writing a response, but in those cases, this change will avoid unnecessarily verbose logging of errors relating to such failures, which generally constitute warning conditions; and will ensure better and more uniform logging of any other sorts of unexpected errors that escape the normal error handling pathways. (Server89199)

• TeamPage's diagnostic reporting tools for the content management repository used for shared files and attachments have been updated to correctly take into account the way the repository implements portable file names, and also expanded to look for additional types of problems. The tools can also now be used from a browser by any user who has Server Setup permission, making it easier to generate the reports without having access to the console of the host machine. (Server89239 / Server89238 / Server89241)

• Changed the default interval governing how often TeamPage updates cached data related to externally defined user accounts and groups from, e.g., an Active Directory service. (Server87426)

For Developers



Tests for User Permission to Erase Entries



TeamPage's permissions model has long included separate ACLs and other rules that effectively govern whether users are allowed to perform deletion operations affecting either all versions of an entry, or just one or more specific versions. In this release, a few "under-the-hood" changes ensure consistent enforcement of these permissions, particularly as reflected in the user interface, and improved failure condition message reporting, particularly in certain corner cases.

TractionSecurityManager API Changes



com.traction.sdk.TractionSecurityManager's checkEraseQ(com.traction.sdk.TractionId) and checkEraseX(com.traction.sdk.TractionId) methods have been replaced with the following separate methods separately covering permission to erase all versions of an entry and specific individual versions:

    public abstract boolean checkEraseAllQ(TractionId target);

    public abstract void checkEraseAllX(TractionId target) throws AuthenticationException, MessageException;

    public abstract boolean checkEraseExactQ(TractionId target);

    public abstract void checkEraseExactX(TractionId target) throws AuthenticationException, MessageException;



For ordinary content entries (articles, comments, etc.), this effectively requires that the user have permission to read all non-erased versions, and either be the original author and have Erase Own permission in the containing space; or have Erase permission in the containing space.

For special "system" entries, such as reclassification records, follow records, etc., this requires permission to administer the containing space (i.e., that the user have Space Setup permission in that space or have Server Setup permission). The com.traction.sdk.Entry.Type.requiresAdministratorToErase(int) method can be used to determine whether an entry's type code -- accessible via Entry's getEntryType() method -- corresponds to one of these system entry types that requires this special permission.

These separate methods ensure that client code can accurately and uniformly indicate to a user what deletion operations will be permitted for a given entry. But since it is not generally advisable to delete system entries, the "Erase" view action will never offer the option to delete a single system entry, even for administrators who would be allowed to do so: this will continue to be possible only in the classic Delete dialog which is accessible from the collector. (Server89119 / Server89120)

Exceptions Produced by NewErasure Methods



In a related change, for the sake of consistency -- as well as ensuring that error messages seen by users reflect appropriate descriptions of any failure conditions -- com.traction.sdk.edit.NewErasure's eraseAllVersions and eraseExactVersion methods will throw a com.traction.sdk.MessageException rather than a com.traction.sdk.AuthenticationException when encountering a request to erase either a specific version that is already erased, or all versions of an entry that has no non-erased versions, as long as the requesting user has sufficient read permissions to allow them to differentiate between these conditions. For example, if a user requests the erasure of an exact version that they are allowed to read but which is already erased, the MessageException will be produced with an appropriate error message describing the condition; whereas if the user is not allowed to read the exact version requested, an appropriate AuthenticationException will still be produced. This will avoid treating a condition which effectively represents an invalid request the same as a request that has been disallowed as a result of permission-related security tests. (Server89116)

"html" Pseudo-Fields



TeamPage's web forms framework now supports an "html" pseudo-field type. This makes it easy to include possibly dynamic arbitrary markup in a form. Making it a field on the client side means that it can be set up to be dependent upon one or more other fields in the form, which means that the markup can be updated when a field changes.

To use this setup, a field should be configured as follows:

# my_custom_field.properties
type=html
sdl=com.example.foo.sdl.gwtrpc.forms#my-custom-field



To make this example psuedo-field dependent upon another field, a custom variation of the "entry" DataSource could be configured as follows:

# custom_entry.properties

__inherits=entry

# Make the "value" of the my_custom_field pseudo-field
# be updated each time the "my_other_field" field changes.
value_dependencies_my_custom_field=my_other_field



When the SDL is evaluated, the com.traction.sdk.data.Field is put into scope as the current Field so that the field.* tags will work; and the "formValues" Map variable can be used to retrieve the current values of other form fields, e.g.,

<!--- com/example/foo/sdl/gwtrpc/forms.sdl -->

<sdl.function name="my-custom-field">
  <variable.local.whitespace name="formValues" index="my_other_field" not>
    <!--- Supposing my_other_field is a reference field, its
          effective value will be the FQID of an entry. -->
    <entries type="single" fqid="${formValues[my_other_field]}">
      <a href="__entry.permalink__" target="_blank">View</a>
    </entries>
  </variable.local.whitespace>
</sdl.function>



(Proteus15457)

Additions to the Proteus JavaScript API



Custom Calendar and Task Filter Control Handling



The controls generated from gwt.rpc.view tags that use name="CalendarControls" or name="TaskListControls" can now be set up to fire "filter-toggle-change" events instead of automatically performing navigation. (Proteus15552)

The following SDL illustrates how this could be done using the events= attribute on the appropriate SDL tag to request this behavior:

<sdl.function name="calendar-controls">
  <gwt.rpc.view name="CalendarControls" events="true">
    <gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_goal}" param="hp"></gwt.rpc.view>
    <gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_milestone}" param="hm"></gwt.rpc.view>
    <gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_task}" param="ht"></gwt.rpc.view>
    <gwt.rpc.view key="filters" label="#{index_entry_type_type_filter_display_name_event}" param="he"></gwt.rpc.view>
  </gwt.rpc.view>
</sdl.function>

...

<sdl.function name="tasklist-controls-box">
  <gwt.rpc.view name="TaskListControls" title="#{sidebox_tasklist_controls_title}">
    <variable.boolean name="changeTags" default="true">
      <gwt.rpc.property.set name="changeTagsRg" value="a#form&form=<variable.value name='changeTagsRg' index='form' default='mrecat' />&pageaction=<variable.value name='changeTagsRg' index='pageAction' default='feed' />&onsave=<variable.value name='changeTagsRg' index='onSave' default='rv' />" />
    </variable.boolean>
    <gwt.rpc.view key="ShowCompleted" events="true"></gwt.rpc.view>
    <scope.haslist>
      <gwt.rpc.property.set name="list-context" value="__list.name__" />
      <gwt.rpc.property.set name="list-ordered" value="<list.ordered>t<else>f</list.ordered>" />
    </scope.haslist>
  </gwt.rpc.view>
</sdl.function>



Plug-in authors can use their own JavaScript to register to receive these events in order to customize the behavior of these controls for views involving calendars and task lists:

(function() {

  function onFilterChange(data) {
    // ...
  }

  function registerMyListeners() {
    Proteus.addHandler("filter-toggle-change", onFilterChange);
  }

  Proteus.addHandler("load", registerMyListeners);

})();


The data passed to the event listener is structured as follows:

{

  /**
   * the name of the parameter
   */
  "param": "hp",

  /**
   * the true/false state of the checkbox
   */
  "checked": "true",

  /**
   * the value that the parameter should generally take
   * when the checkbox is in that state
   */
  "value": "f"

}


To query and modify these controls, the following functions may be used:

Proteus.FilterControls = {

    /**
     * Returns true if there is a filter with this parameter name.
     */
    hasFilter: function(parameterName) {
    },

    /**
     * Returns true if present and checked; false otherwise.
     */
    isChecked: function(parameterName, defaultValue) {
    },

    /**
     * Sets the state of the checkbox without firing an event.
     * Returns true on success and false otherwise.
     */
    setChecked: function(parameterName, checked) {
    }

};



Other New Proteus Event Types



Some new types of events have been added to the Proteus skin JavaScript API. (Proteus15574)

Reference: SDK339

These are defined as follows:



Filtering for com.traction.sdk.token.ReferenceBucketEntryFields



Filtering using the built-in "Filter" menu for com.traction.sdk.token.ReferenceBucketEntryFields, which are driven by com.traction.sdk.data.ReferenceBuckets, now functions properly. It is now possible to support filtering for these EntryFields using a configuration like this:

# plugins/com.example.foobar/config/entry/fields/props/bar.properties

class=com.traction.sdk.token.ReferenceBucketEntryField

# Defined elsewhere in plugins/com.example.foobar/config/data/referencebuckets/bar.properties
reference_bucket=bar

filter_selectable=true
filter_group=baz
filter_order=5287
filter_display_name=Bar
filter_field_type=reference_bucket_select


Using the filter_field_type=reference_bucket_select allows the user to select one or more entries in the filter form so that they can use the "Any" search type to find matches for any of the selected entries.

Context Menu Customizations



The TR elements used to display each of TeamPage's custom context menu items now come with a class="cm-row-{item name]", e.g., class="cm-row-AddLabels" or class="cm-row-Copy" so that the layout or style of individual context menu items can be more easily customized, including hiding them using "display: none". (Server87476)



Article: Customer5091 (permalink)
Categories: :Doc:changelog, :Doc:r62
Date: August 11, 2018; 2:52:00 AM Eastern Daylight Time

Author Name: Dave Shepperton
Author ID: shep