Title: TeamPage 6.2

Traction® TeamPage 6.2 is a major release incorporating many changes and improvements since TeamPage 6.1.24. This release is focused mostly on "behind-the-scenes" changes and improvements to APIs used by developers to customize and extend TeamPage, bug fixes and improvements, and substantial refactoring to improve the structure of the the TeamPage code base.

Important note for customers who have in-house customizations: please be sure to read the "For Developers" section.

Download TeamPage 6.2


Impi! Solutions for Project Management



Improvement Projects (Impi! / Traction Continuous Improvement System)



We've continued to work with Impi! Solutions to add features and capabilities.

Threat and Opportunity Module



This new module, also developed in conjunction with Impi! Solutions, helps organizations get a handle on any risks posed by threats to business processes. To prescribe risk mitigation measures, users can create innovation tasks or, with the Improvement Projects module, new Improvement Opportunities which can then be followed up on with Improvement Projects.

Bug Fixes



• Fixed a bug that could prevent the Documents view from being displayed for a particular folder if that folder has a description entry (created via the "Describe This Folder" action). (Proteus14425)

• Fixed a bug that could prevent temporary files from being cleaned up when an associated personal draft was deleted without an entry having been created. To address this issue retroactively, on the first startup after upgrading to this version of TeamPage, your server will also delete all temporary files not associated with in-progress personal drafts. (Server83373)

• Fixed a bug introduced in a recent TeamPage release which could prevent stylesheets and some other static resources contained in plug-in packaged from being retrieved when the TeamPage service was running in a Microsoft Windows environment. (Server83827/JPBO14474)

• Fixed a bug that could cause an unexplained error to appear in the Email Reply form when the user attempts to submit the form when a Reply-To address has not been specified. (Server82622)

• Fixed a bug that could prevent a TeamPage server's caches from being successfully cleared in certain cases. (Server83835)

• Fixed a bug that prevented a user name change from being properly reflected in the ACLs or Groups manager dialogs. (JPBO14782)

• Fixed a bug that prevented custom color stylesheets from being applied. The changes were correctly previewed while the custom stylesheet editor was in use, but would disappear after the changes were saved. (Server83869)

• Fixed an issue that could, in some unlikely circumstances, cause a file descriptor to be leaked when attempting to use TeamPage's text file inspector to review a log file. (Server83892)

• Fixed an issue that could prevent a newly selected keystore password from being used until a TeamPage server was restarted, preventing an existing keystore from being read, or even preventing a new keystore from being created, e.g., to track trusted certificates. (Server83864)

• Fixed a bug that prevented the locale-specific first day of the week from being correctly applied when scoping a view or query to a particular week. (Server83920)

• Fixed a bug that could prevent a TeamPage server from sending a cancellation notice for certain events created using the Standard Meetings module. (Server83704)

• Fixed a bug that could prevent a TeamPage server from starting up if a plug-in with a particular type of incorrect package structure had been unpacked in the settings/plugins/pending folder. (Server83689)

• Fixed a bug that could prevent a plug-in space settings dialog from displaying in certain cases. (Server83325)

• Fixed index-time static document boosting for Apache Solr integration. Static scoring boosts were applied to documents as they were dispatched to the Solr server, but those will now be correctly used at query time. (Solr757)

• Fixed an issue that caused bounce messages, sent when an email message read by a TeamPage server cannot be processed to create a new entry, to be sent even when the message headers indicate that no such messages should be sent. (See RFC 3834.) (Server83650)

• Fixed a bug that could cause an error preventing in-page notifications from being correctly marked as read in certain cases. (Server83690)

• Fixed a bug that could prevent type-ahead completion of spaces in forms (e.g., the "New Article" form) from offering completion against space display names. (JPBO14286)

• Fixed a bug that prevented the Space Template dialog's topic tag control from being rendered correctly. (Server83598)

• Fixed a bug that could prevent a search engine Index Administration dialog from being displayed in certain cases. (Server83729)

• Fixed a bug that prevented the text "Delete Files" from appearing as the label text for the button in the server settings > Server Files page's Other Files > Uploaded Files area for cleaning up temp files. (Server83355)

• Fixed a bug that could prevent logo images from being stored in the correct location when running the TeamPage server with certain environmental configuration options. (Server84049)

• Fixed the class= style names applied to the HTML BODY tag in various Status views. The class= attribute on the BODY tag is now correctly set to "view-status", making is possible to selectively customize styles applied to TeamPage's Status views. (JPBO14444)

• Fixed a bug that could prevent users from being able to successfully authenticate using TeamPage's premium NTLMv2 support module. (Server81583)

• Fixed a bug that could result in a template entry being erroneously loaded when clicking, e.g., the "New Article" button in the side column if a template had been loaded during a previous invocation of the same form and then the form had been canceled or otherwise closed without the new entry being submitted. (Proteus14518)

• Fixed an annoying bug that could cause the space selector in the Email Articles form to "forget" which space was selected, and default back to the first available space, when one of the rendering options (e.g., "Include tags" or "Include headers") was modified. (Server84649)

• Fixed a spacing issue with some text in the ACLs and Groups dialogs' add user/groups controls. (Server84578)

• Fixed a longstanding issue that could cause the comment form and/or comment hover menu/context menu actions to be available in certain situations when the user interface should not offer the option to comment, including when the target entry has been erased. (Server52743)

• Fixed a bug in TeamPage's internal SDK implementation level API that could cause duplicates to appear in the set of references for a particular entry. This bug is not likely to have affected features outside of certain customizations, such as the Tag Change Report plug-in (available in the contrib/plugins folder of the "teampage" open source repository). (Server84569)

• Fixed a bug that could prevent some documents (e.g., PDFs) from being successfully added to the index of an Apache Solr server (to be later displayed in TeamPage search results) if the document contained custom fields that collided with certain essential fields specified for the indexer by the TeamPage server. Such custom document fields are now correctly added to documents in Solr's indices using namespaced document field names that are sure not to collide with field names reserved by TeamPage. (Solr841)

• Fixed a bug that could cause a value for the CC field in the email reply form to be used for the BCC value, also. (Proteus14588)

• Fixed a bug that could cause the email message sent using the Email Reply feature not to send the entire message body in certain cases. (Server84949)

• Fixed a bug that prevented certain extra data stored with an article, comment, task or other entry content from being included in TeamPage's native fulltext index. (Server84875)

• Fixed some issues related to file security and file path mapping for certain types of resources, such as logo images. It is unlikely that customers experienced any problems related to the underlying issues, but in certain cases involving a particular set of TeamPage service configuration options, logo images might not be able to be displayed. (Server84798 / Server84801)

Other Improvements



• TeamPage now sets the email header "Return-Path: <>" on digest and notification email messages. This is a standard method for indicating that automatic replies (such as those that would be generated by an "Out of Office" responder) should not be generated in response to these messages. Note that the "Auto-Submitted: auto-generated" and "X-Auto-Response-Suppress: All" are also set on other email messages that are automatically generated by TeamPage. (Server82491)

• TeamPage's default "Ignore Auto-responders" filter for incoming messages is now based upon the presence of any of the following email message headers:

X-Autoreply: (any value)
X-Autorespond: (any value)
Auto-Submitted: auto-generated


This filter was formerly based upon the following headers:

Auto-Submitted: auto-replied
Return-Path: <>


But in some circumstances, using those headers to select incoming messages to be discarded could have produced "false positives" that could result in ordinary incoming messages being discarded. Moreover, many automatically generated replies that should have been discarded were still accepted, leading to the possibility of an "auto-responder loop." The new matching formula is based upon more widely accepted industry standards for filtering messages generated by auto-responders. Customers who need to do so can still create their own custom filters. (Server82489)

• Added some new project management related entry fields that can be used in section tables that show projects or milestones: the total number of tasks in the project or milestone; the number of completed tasks in the project or milestone; and the percentage of a project's or milestone's tasks that have been completed. (Server84041)

• Modified the way that the Signature Requirements module logs diagnostic information to prevent unnecessary noise in TeamPage's log files. (Proteus14452)

• Index-time static document boosts, applied when dispatching documents to be indexed by external search engines, has been improved; and the scale of the boost as applied for indexing in an Apache Solr server has been increased so that the boosts will have a useful impact on final result scoring. The static boost now covers all of the following properties and aspects:



In order to pick up the effect of these changes, customers using Solr with TeamPage should clear the contents of their existing collection in the Solr index and re-feed all documents from TeamPage. Both of these operations can be done from the Solr Index Administration dialog, accessible from TeamPage server setup (type "Solr Index Administration" into the setup search box at the top of any setup page). (Server83369 / Server83370)

• Solr query results now also correctly rank results higher (all other things being equal) when fulltext search terms are matched in the title of an entry or the name of an attachment or other file. (Solr770)

• Improved handling of certain unexpected conditions when displaying an inline comment form. This can prevent unexplained errors from causing a page to malfunction in the extremely unlikely (but possible) scenario in which TeamPage presents an inline comment form that is missing certain required elements. (Server83565)

• Fixed various issues with the Table of Contents widget. This widget was contributed by a customer, and is not a supported part of the Traction TeamPage product, but is so widely used that we were compelled to address these issues in support of the many customers who make use of it. (Server83705)

• Made some modifications to smooth out some issues that could occur in a task list when a user clicks a task checkbox to toggle between the open (to do) and complete (done) states and rapidly expands that same task to reveal the full task entry content and details. This should prevent the JavaScript errors that some users have reported in this situation. (Server82162)

• The project and/or milestone associated with events appearing in a Calendar view are now displayed in a tool tip when a user hovers their mouse cursor over the event link text. (JPBO14741)

• The Filter menu's "Meetings" filter group, which is part of the Standard Meetings module, now appears below other built-in filter groups, such as "Project Management" and "General". (Server83949)

• Optimized the creation and rendering of certain special "synthetically generated" paragraphs so that they are not generated when they won't be used, and not rendered until they are needed. These paragraphs do not exist as ordinary items in TeamPage journal entries; rather, they are "synthetic" paragraphs created by TeamPage at display time to present special metadata or auxiliary information associated with a given entry, when applicable. This includes the name and email address provided by a person who posted a comment as Visitor; the information about the RSS or Atom feed item from which an entry was created; and other application-specific information, such as section-like renderings of various types of associated entries. (Server84632 / Server84636)

• Removed requirements for the Social Enterprise Web (SEW) features to be licensed in order for the "Describe File" / "Describe Folder" features to work consistently. Previously, SEW licensing was required to use these features. That requirement was nominally removed in an earlier TeamPage release, but there were still some places where that requirement was being enforced in an indirect way. (Server84865)

For Developers



Public SDK API



This release includes some incremental binary incompatibilities with earlier versions of TeamPage. If you have any custom Java classes that use any of the following modified public SDK API elements, you may have to make changes to your code and/or recompile your Java .class files before they can be successfully used with this version of TeamPage. (If your custom plug-ins include configuration files and/or SDL templates only, these changes should not affect you.)

New Built-in Sorting Capabilities



com.traction.sdk.Journal methods that return EntryIterators now support sorting in chronological or reverse chronological order by entry start date. This is useful for sorting tasks, events, and other entries that have start dates. To request results to be sorted using one of these orderings, pass one of the new com.traction.sdk.CJournalRequest constants SORT_START_DATE_EARLIEST_FIRST or SORT_START_DATE_LATEST_FIRST to com.traction.sdk.JournalRequest's setSortOrder method.

Those same methods now also support completely custom sorting using a java.util.Comparator (specifically, a Comparator<? super Entry>). To request that results be sorted using a custom Comparator, pass the Comparator to JournalRequest's setCustomSortOrder method. Invoking this method will also set the sort order constant to CJournalRequest.SORT_CUSTOM.

"flattened thread" and "flattened sub-thread" Queries Now Omit Duplicate Results



Sometimes, a comment / reply entry targets multiple entries. When those target entries are part of the same comment thread, the handling of the "flattened thread" and "flattened sub-thread" in previous versions of TeamPage would cause such comments to appear multiple times in the iteration. The "flatthread" and "flatsubthread" query types for the <entries> tag (see also com.traction.sdk.Journal's getThreadEntries method) will now include those entries just once. (Server82245)

com.traction.sdk.props.GetObject.Loader<T> Now Extends java.util.function.Function<String,T>



This is intended to make it easier to share Functions that map String serializations to objects between general utility methods and cases where such objects need to be loaded from a GetObject, such as those representing server, journal, user or space setting configuration property stores. (Server83702)

Changes to Hierarchy for Some Standard com.traction.sdk.view.ViewAction classes



The class hierarchies for the several standard com.traction.sdk.view.ViewActions and ViewActionDisplays have changed. In particular, there are some new abstract classes in com.traction.view.action which serve as new nodes in the type graph for the standard com.traction.view.action.NewArticle, Update, Reclassify, ReclassifyPopup and ReclassifyMultiple ViewActions. Each abstract class also has an inner abstract class that extends com.traction.sdk.view.ViewActionDisplay, intended to provide a super-type for the corresponding ViewActionDisplays created by the ViewActions.

• com.traction.view.action.AbstractFormLauncherViewAction and AbstractFormLauncherViewActionDisplay: intended as a super-type for a ViewAction/ViewActionDisplay that provides a link or button for launching a form.

• com.traction.view.action.AbstractEntryFormLauncherViewAction and AbstractEntryFormLauncherViewActionDisplay: intended as a super-type for a ViewAction/ViewActionDisplay that provides a link or button for launching a form for creating or manipulating one or more entry. They extend AbstractFormLauncherViewAction and AbstractFormLauncherViewActionDisplay, respectively.

• com.traction.view.action.AbstractNewEntryFormLauncherViewAction and AbstractNewEntryFormLauncherViewActionDisplay: intended as a super-type for a ViewAction/ViewActionDisplay that provides a link or button for launching a form for creating a single new entry. They extend AbstractEntryFormLauncherViewAction and AbstractEntryFormLauncherViewActionDisplay, respectively.

NewArticle and its now extends AbstractNewEntryFormLauncherViewAction; Update and other standard classes now extend AbstractEntryFormLauncherViewAction. Also, all the inner ViewActionDisplay classes for the ViewActions in these type hierarchies are no longer declared as static member classes. That is, the "static" keyword has been removed from the class declaration, and each instance has an "enclosing instance" of the ViewAction that instantiated it.

These refactorings are intended to provide better abstractions of the generic super-types for ViewActions and ViewActionDisplays. There may be further changes along these lines in the future.

com.traction.sdk.SdkFactory's getFileRef Method Moved to com.traction.sdk.Journal



The getFileRef(String, Context) method has been moved from SdkFactory to Journal. This is consistent with the Journal providing access to document-type objects: even though a FileRef is not a document object, per se, it provides an interface for operations on a file resource. There may be other changes along these lines in future so that the API better represents the Traction data model.

com.traction.sdk.file.AttachmentStore Changes



The AttachmentStore interface is still present in the public SDK API, and like, e.g., com.traction.sdk.admin.UserDirectory or the various UserDirectoryComponents, it still represents a customizability/extensibility point in the Traction API. But the public SDK API no longer manifests any AttachmentStore instances. Instead, AttachmentStore instances are used and entirely contained by the SDK implementation layer.

Developers should use the com.traction.sdk.Journal public SDK API methods such as getFile and getAttachment to retrieve instances of individual com.traction.sdk.File or com.traction.sdk.Attachment objects in the absence of, e.g., a com.traction.sdk.Entry object from which a com.traction.sdk.iter.AttachmentIterator could be retrieved.

com.traction.sdk.UserContext and com.traction.sdk.RequestContext Removed from Public SDK API



These interfaces represent important elements to be used by the SDK implementation layer, but are not a proper part of the public SDK API. The com.traction.sdk.Context for the current request (which is available, e.g., as an instance field on any com.traction.sdk.view.TractionView) is always the nexus for request-specific information, including the user, their permissions, etc., which might formerly have been specified by a UserContext; and an appropriately configured com.traction.sdk.CJournalRequest / JournalRequest will generally provide information such as whether or not "draft preview" mode is activated for a particular query, which might formerly have been specified by a RequestContext.

Also note that the com.traction.sdk.Document interface, and its com.traction.sdk.Entry sub-interface and com.traction.sdk.File and com.traction.sdk.Attachment sub-classes, all now offer the public method

public Context getContext()


The signatures of all methods on the File and Attachment classes that formerly accepted either a UserContext or Context have been modified to remove that parameter, since the Context is accessible either internally or via the getContext method (and the same sort of modification will be made to the Entry interface and its implementing classes in a future release).

com.traction.sdk.file.FileInfo's getLocalFile Method Removed



Not every FileInfo is backed by a local file on disk, and therefore not every instance corresponds to a java.io.File. The idea of the FileInfo interface has been to encapsulate access to an abstract file, bound to an abstract URI or URL rather than to a location on disk. This method therefore was at odds with this model, violated the encapsulation of FileInfo implementations, and was furthermore unnecessary.

Clients should use the getInputStream method to access an InputStream for the underlying file, regardless of its underlying storage mechanism; getFileData to access a com.traction.sdk.file.FileData object describing its attributes; or other methods to retrieve other properties, such as getByteSize.

Side Notes on Temporary Files in TeamPage


Some temporary files are "temporary" in that they are not persisted to the main Traction TeamPage backing file store (or at least not yet), but may persist for some time longer than a single request. The special type of FileInfo, com.traction.sdk.file.TempFile, is intended to be used in this case.

Its getOutputStream method provides access to an OutputStream for the underyling temporary file, which parallel to FileInfo's getInputStream, is agnostic to the underlying "file" storage mechanism; and its save and delete methods can be used, respectively, to commit changes or remove the corresponding object from the backing store.

The current com.traction.sdk.TractionRequest, accessible via the current com.traction.sdk.Context's getRequest method, provides access to TempFiles representing any files that have been uploaded as part of the current request. com.traction.sdk.SdkFactory, meanwhile, offers various for either retrieving TempFile objects backed by a reference to an existing (previous created/uploaded) temporary file resource, or a new TempFile allowing client code to create another temporary file on behalf of the user that the request is running as.

When it comes to truly transient temporary files, which are not intended to survive beyond the life of a single request, use a com.traction.sdk.file.TransientTempFile. Instances can be created directly using its factory constructors. Examples of appropriate uses of TransientTempFile include the multi-stage document rendering operation used in TeamPage's built-in PDF export feature (see com.traction.sdk.export.FopPdf). TransientTempFiles are backed by a "real" file on the local file system. They don't require the overhead associated with implementing the FileInfo or TempFile interfaces, but they still provide a useful abstraction beyond those provided by Java's built-in temp file support (limited mostly to java.io.File.createTempFile), including graceful handling of errors relating to environmental conditions that might prevent the creation of a temporary file.

Forms API



Configurable Dynamic Updates to Field "Data" via FieldType.DataProvider on Form Field Value Changes



TeamPage's GWT forms API now supports supplying updated "field data," in addition to updated field values, when another field's value changes. This includes the often-missed capability to change the OPTIONs offered for a SELECT field based upon another field's value.

Field-to-field dependencies are still defined in configuration for the com.traction.sdk.data.DataSourceFactory configuration. (See, e.g., the built-in abstract configuration at config/data/source/entry.properties.) In the future, this may change so that dependencies can be defined across sources in the com.traction.sdk.data.FormFactory configuration.

Form Dialogs



TeamPage's forms API now offers a new type of form dialog intended to be used to display a form that is itself being used to offer configuration options for launching another form. To select this type of form dialog, the region token dialogType= property should be set to "setup."

On successful submission of a form from this type of dialog, all the form properties that are communicated back the client which start with "next_" will be used to specify the bootstrap properties for the "next" form. The next_dialogType= property may also be specified to indicate the type of form dialog to use for that next form. The valid values are "setup", for another setup form; "navigation" for a navigational form; "schedule" or "task" for a form that will be used to schedule a new event or create a new task, respectively, referring to a particular entry content item; "proxy" for a new proxy entry form; and "entry" for a new ordinary entry form dialog. (The default value is "entry".)

Required Fields



TeamPage's SDL libraries for generating custom HTML form layouts now support the the required_indicator= form field boolean configuration property (defaulting to false). When this property is true, the required field value indicator will be automatically rendered in the custom HTML layout for that form field. (Proteus14445)

New AssociatedProjectsLabelNameBucket and and Client-Side Field Type



TeamPage now has a special new type of LabelNameBucket class, tsi.sdk.data.AssociatedProjectsLabelNameBucket, which is intended to collect all com.traction.sdk.Label instances that correspond to a given label name across any spaces. This effectively represents a way to associate spaces with an entry that supports this bucket type. For example, to create a LabelNameBucket that represents the spaces a special "process" entry is associated with, a LabelNameBucket configuration can be created with class=tsi.sdk.data.AssociatedProjectsLabelNameBucket and label_name=process. That special entry could then be considered to be associated with any spaces whose "process" tag it carries.

The new "labelselect_projects" client-side form type supports any fields that are associated with this type of LabelNameBucket, by offering a "pill box" style control that allows the user to select which spaces are associated with the entry in this fashion (and/or to remove any previously selected spaces). Fields that use type=labelname_bucket_select will automatically use this type of client-side field if they are associated with a tsi.sdk.data.AssociatedProjectsLabelNameBucket. (Any Field using a FieldType configuration set to class=tsi.sdk.data.field.type.LabelNameBucketLabelSelectFieldType that does not have an explicit gwt_type= property will also use that type of client side field when associated with a AssociatedProjectsLabelNameBucket.)

Support for Regular Expression Pattern Match/Replace for Deriving Tag Display Names in List Type Matchers



TeamPage now supports the pattern= and replace= properties for dynamically deriving display names for tags that are claimed by LabelNameBuckets using type=list. If the pattern= and replace= properties are specified, they will be used, respectively, as a regular expression pattern specification and the replacement text format (meaning they can make use of references to capture groups defined in the pattern) that will be used to derive display text for a LabelName or Label instance claimed by the LabelNameBucket.

Support for Numeric Valued Form Fields



Developers can now configure their custom fields to use the "number" field type. If the browser supports type="number" INPUT elements, that will be used directly; otherwise, special handling will be applied to an ordinary type="text" INPUT.

This type of field supports the following additional field configuration properties:



Showing Form Field Tips in Help Dialog



The availability of a helpful tip or additional descriptive text for a form field is now indicated by a help icon next to the label text, and clicking the icon will show the tip text. (Proteus14558)

"Explain" Static Document Boost Computation



The com.traction.entrypropsviews plug-in, which is installed and enabled as part of the default TeamPage installation, now displays detailed information on the computation of the index-time static document boost, per external search engine configuration. This information is also displayed in a view of external search results, along with other arbitrary document field name-value pairs, when the extsearch-debug URL parameter (or view state token parameter) is present.

This explanatory information can be useful in determining why a document appears where it does in a set of search results that are sorted by rank. Developers and users, though, should keep in mind that both in the case of the Attivio AIE search module and the Apache Solr search modules, the search engine's internal algorithm for scoring is mostly a "black box," and the static document boost is only one element in the formula that is used by the engine to score results at query time.

Other



• Developers can now more easily insert one or more custom "entry tabs" after the built-in article/draft/published version tabs, by selectively overriding the "entrytabs.placeholder" function in the shared.sdl template located in the com/traction/sdl/gwtrpc of their plug-in. (JPBO14981)



Attachments:
tp62_avenir.png
Related Articles
referenced by (1)
Customer5209: TeamPage 6.2.44
Article: Customer4991 (permalink)
Categories: :Doc:changelog, :Doc:r62
Date: November 1, 2017; 9:01:00 PM EDT
Author Name: Dave Shepperton
Author ID: shep