(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:
- incoming cross-references to an entry;
- outgoing cross-references from an entry to other entries;
- the total number of tags on an entry, including all tags on individual paragraphs;
- whether an entry has tags from other spaces;
- whether an entry has a "headline", "bulletin" or "news" tag;
- the number of updates that have been made to the entry;
- the number of attachments the entry has;
- the size of the entry's discussion thread;
- the number of directly comments and replies to an entry;
- the number of wiki page names an entry has;
- whether an entry has global wiki page names, or page names scoped to another space;
- the type of entry (normal article vs. named wiki page, vs comment/reply, vs. milestone, project, event or other special entry type).
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.
